Subject: [Sipping] Comments on config package

From: Goix Walter <[email-masked]>
Date: Sat, 08 Jan 2005 01:09:36 +0100

Some comments/question regarding the draft:

- Like Cullen, I don't see what application profile means in this context. Why would a user agent subscribe for it, which kind of information should this provide? What is the intended use of the "app-id"? It is not clear why it is only optional with "application" profile type: again, which type of information is provided when no app-id is provided? Is it expected to standardize "app-id" values together with some application-dependent content-type, such as OMA push-to-talk configuration or similar?

- The package makes use of the "vendor", "model" and "version" parameters in the Event: header to identify the type of UA, which is requesting a configuration. In many cases, SIP UA can be made of many librairies put together to define a SIP client, such as the stack itself and the GUI for example. Many existing implementations share the same stack but offer different features or GUI, and are even reselled by different "SIP client" vendors. In this case, which value is expected to be filled into these parameters? Would such a situation trigger more than one subscription for each part, and its related vendor/model/version? In some cases, configuration provided by the server may further depend on the actual combination of the parts, and not simply relying on a single part separately. How would be the package used in that case? May not just the User-Agent: header be used for this purpose, requiring it in SUBSCRIBE messages. Many vendors already provide all embedded parts of the client there.

- I don't see that much the need for the network-user parameter, especially if with MAY strength. It is not clear when the server will actually perform authentication. I guess authentication will hardly be performed if the client do not include it in the SUBSCRIBE request, but hardly see the value added if the client provides it in the request. There is no mechanism for the server to require the insertion of this value from the client (except out-of-band mechanisms...). Hence, how would a server behave if it doesn't get this parameter, while it does authenticate users when the client provide it? Furthermore, which kind of differentiated information would the server provide to users it authenticates with respect to other users? Finally, such profile types (local and device) would typically be owned by servers, which can be different from the user profile delivery server, i.e. from the profile that knows anything about the user (its password for example) and can actually perform authentication. No procedure is defined in case the device/local profile server wants to check user identity but do not owns it. 
A potential use case for such a scenario I can envision is roaming. I would imagine a user agent booting in its "home" local network may add the network-user parameter when subscribing to its local profile, while it won't include it when it enters a "visited" network. Information provided from its "home" network may provide a premium access with respect to other "visiting" users. Differentiation between home and visited networks may be based on DHCP domain name checked against user's AOR domain name. Is that a reasonable scenario?

- What is the need for the 'document' parameter? Aren't all the other parameters enough to identify the type of information to retrieve? This further require the server to support XCAP queries and embed an XCAP client. No such requirement is provided in the specification. What if the client ask for it and the server does not support it? It seems to me that the use of XCAP with this package would need to be clarified. SIMPLE xcap-package seems to define part of the XCAP+sip-profile mechanism as well, but also need clarification.
If the intention is to make a intensive use of XCAP doc changes with this package, then both parts would probably better to be merged into a single one for clarification. In that case, I would rather remove XCAP-related recommendations from this spec (e.g. use of app-id as XCAP AUID) and insert them to the xcap-package, since they are likely a example of use of this package (it already defines XML schema and content-type).

- There is no mention of profile "fetch" capability. I supposed this is implied by the definition of the package but this may also be worth specified since it would avoid subscription state in the server, especially for long-term subscriptions with few updates. A recommended value minus a random offset may be sufficient in most cases (except obviously for emergency updates, but this may still be acceptable).

Walter Goix

Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to
[email-masked]. Thank you
====================================================================

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP