Add Profile related test for writes.

We have added more limits and capabilities (via your other mantis issues). Certification has always checked all limits and ensure that server (under normal operations) honor there limits [limits can be missed as stated in the specification]

If you have specific limits that you would like please provided a more specific Mantis issue, so it can be addressed. server behavior can vary a great deal (Nano device to standard cloud server - so minimum limits are far to apply, unless they are very basic - i.e. 1 session, 1 subscription etc.

There is a missing operational limit for the Browse service request but I don't think it can be fully addressed with a server property. I raised this during the F2F and got pushback from Matthias, but this needs further discussion because the client does not have sufficient information to know what the limit should be, and according to Matthias, neither does the server.

The Nodes in the Server may have any number of references: 0 < References < infinite. The client has no knowledge of the number of references each starting node has, and for max efficiency will create requests with as many starting nodes as possible up to the value of MaxNodesPerBrowseRequest. The Browse service takes a parameter called "requestedMaxReferencesPerNode" which supplied by the client (this is not one of the operational limits but something is needed). The spec says this parameter "Indicates the maximum number of references to return for each starting Node specified in the request. The value 0 indicates that the Client is imposing no limitation (see 7.5 for Counter definition)." (EDITORIAL: I have no idea why the Counter definition is mentioned here, really does not belong).

To me this means that this argument indicates the client's ability to process results and throttles the server's reply if it cannot keep up. It does not mean it is used to keep the reply data within the limits of the server or its infrastructure. This would not make sense anyway since the client has no knowledge of the server's or network's constraints at the server's location. If that is its intended purpose the spec should state that, but it still makes no sense since would a general purpose client cannot "know" what the server can handle.

In our case the client can handle any size reply so it calls the Browse service request with argument "requestedMaxReferencesPerNode" set to 0.

This usually works but we ran into a use case where the Browse request failed with error BadEncodingLimitsExceeded (in our testing this error was was returned in the reply message, which means it was generated server-side). When this occurs it is difficult to diagnose the root cause or how to fix it because there is no information available on what the limit should be, or what caused it to exceed the limit. If this occurs in the field it will result in a support call that will probably get escalated to the engineer (i.e. user->hisBoss->salesman->support->supportBoss->VP->myBoss->me ==> badThingsHappen up and down that chain ).

The ideal solution is where the system contains sufficient information for automatic configuration so that it just works. Configurable options should be applied at the site where the necessary data exists. For example, if the server can send 100K references in a reply it could check if the encoded message exceeded some internal limit and start using continuation points when it hits that limit.

If this is a server side limitation then the server should set this, not the client. If the client must set this value and must account for server side limits then it needs more information:

• number of references in a node (this ought to be contained in a BrowseReply message anyway for other reasons)
• the size of a reply for each reference
• the max size of a reply the server can handle

If I am using the API incorrectly then please explain how the client should determine what this limit it.

the requestedMaxReferencesPerNode - is a client side throttle. The server that had an encoding problem is broken - it is suppose to return a continuation point and what can fit in the response, with the remainder in the browsenext call(s)

I ss no change needed in the API, only a fix to the broken server.

submitter agrees to close with no change required.