Subject: RE: [Sipping] Comments on config framework draft- URIs and event package parameters

From: Simonetti Gabrielle <[email-masked]>
Date: Tue, 26 Oct 2004 20:38:07 +0200

Dan,
inline.

> -----Original Message-----
> From: Daniel G. Petrie [mailto:[email-masked]]
> Sent: venerdì 22 ottobre 2004 21.28
> To: Simonetti Gabrielle
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Sipping] Comments on config framework draft- URIs and
> eventpackage parameters
> 
> Simonetti Gabrielle wrote:
> > 
> > > Section 3.13.1
> > > --------------
> > >
> > > - What if instance does not matter? Example all Nokia phone
> > > 6600 model require the same profile, instance does not
> > > matter. Vendor and model is the only thing needed to download
> > > a profile. There is no need for the service provider to have
> > > separate profiles for every device, especially will they are
> > > identical.
> > 
> > I agree that the instance-id might not matter in the case 
> of the "device" profile. In fact using the instance-id 
> creates unnecessary subscription targets, as these can be 
> grouped by "model", for example, as you say.
> > 1/What do you suggest for the format of the subscription 
> URI then, leaving out the instance-id?
> > 2/The question has already been raised whether "vendor", 
> "model" and "version" are sufficient to identify the precise 
> profile to be delivered, e.g. in the case where a particular 
> UA model has different components, each with its own version 
> number. A possible solution would be to define a new 
> parameter "component" for the Event Header to identify the 
> component for which the subscription is made.
> 
> The instance-id does matter in the device profile when you 
> consider the
> boot strapping of a new user agent.  Out of the box a new UA 
> only knows 
> its instance-id (or how to generate one).   It also knows how 
> to use its
> instance-id to form the URI to subscribe for the device profile.  The
> device profile needs to contain the default user AOR so that the UA
> can subsequently figure out what user profile to subscribe to.  Hense,
> minimally all device profiles may differ by the value of the default
> user AOR.
> 

Let's consider the case where the device profiles are delivered by a server within the constructor (that manages the UA versions): the constructor might not be aware of the identity of the users using the devices. On the contrary, the service provider is the one holding the user profiles, and could thus keep an association between instance IDs and default AORs. In addition, in some cases, the access provider coincides with the service provider... Have you considered including the default AOR in the local profile together with the other SIP parameters rather than in the device profile? 

> This is not the only deployment strategey, but it is certainly one
> we want to support.  Other deployment strategies are also supported:
> 
> 1) preprovisioned UAs which know their default user's AOR.
> 
> 2) UA's which prompt the user for their AOR
> 
> Regardless, I think that we still want to make the instance-id
> manditory as the user-id part of the device subscription URI.
> The fact that the profile delivery server may deliver the exact
> same profile to all devices of the same vendor, model and version
> is an implementation choice.  Without the vendor, model, version
> and instance-id the profile delivery server does not have a choice
> to be smart or dumb.
> 

ok.

Gabrielle

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