Subject: Re: [Sipping] Comments on config package

From: "Daniel G. Petrie" <[email-masked]>
Date: Tue, 15 Feb 2005 01:40:10 -0800 (PST)

Sorry for the delayed response.  Thank you for
your comment.  Comments below:

Cheers,
Dan

--- Goix Walter <[email-masked]> wrote:

> 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 application profile is intended to contain
profile information that is application specific.
The application profile supports the notion that
there is a wide varity of user agent capabilities.
Some user agent support telephony like functions
only.  Some support IM only.  Others support both.
The application profile provides a means to separate
data that pertains to specific capabilities.

The app-id and document parameters provide filtering
capabilties.  If the user agent only wishes to
retreive specific profile data, these parameters
provide the mechanism to be more specitic.  In the
wireless space where bytes count, this filtering
capability is important.

I will try to clarify this in the 06 draft that
I am updating now.

> 
> - 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.
> 

The Vendor, Model and Version are intended to be
specific to the assembly not the parts that 
went into the user agent.

> - 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?

The local network provides a generic profile unless
the network-user parameter is provided.  The user
agent provides the network-user only if the user
as some prior arranged privilages in the local 
network.  It is the local networks policy decision
to authenticate if network-user is provided.

I will add text to clarify this.

> 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?

Sure
> 
> - 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
A SUBSCRIBE with Expires=0 is a one time fetch as
defined in RFC3265.  The subscription state actually
performs an important function. It identifies which
user agents are currently enrolled or active.

> 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).
> 

SOrry, I did not follow this.

> Walter Goix
> 
> 
> Gruppo Telecom Italia - Direzione e coordinamento di
> Telecom Italia S.p.A.
> 
>
====================================================================
> CONFIDENTIALITY NOTICE
> This mess
age 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
> 

_______________________________________________
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

---

From: Goix Walter <[email-masked]>
Date: Tue, 15 Feb 2005 11:39:40 +0100

Better late than never ;-)
Comments inline...

[snip]

> capabilties.  If the user agent only wishes to retreive 
> specific profile data, these parameters provide the mechanism 
> to be more specitic.  In the wireless space where bytes 
> count, this filtering capability is important.
> 

[walter] Ok. I'll check the new version ;-). Will you also add something
regarding the standardization of app-id values?

[snip]
> went into the user agent.

[walter] So would these values correspond to the physical device model
or still to the overall wrapping of the UA? This may need to be really
clear in the draft.

[snip]

> I will add text to clarify this.

[walter] ok. It would be important to understand the mechanisms that the
UA could use to know in which type of network it is, i.e. if it has to
provide the param.

[snip]

> SOrry, I did not follow this.

[walter] My intention was to suggest some alternative to a long-term
subscription, by using "fetch" SUBSCRIBEs and recommend a polling time
(fixed value - random offset) which could be acceptable in some cases as
a configuration mechanism. I'm not sure I am still convinced of such an
approach, and am especially concerned on how to force a UA NOT to do
fetching if the provider wants to use real-time notifications (and hence
need subscription-state).

walter

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
====================================================================