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

From: "Daniel G. Petrie" <[email-masked]>
Date: Mon, 1 Nov 2004 14:16:24 -0800 (PST)

Comments below:

Cheers,
Dan

--- Simonetti Gabrielle
<[email-masked]> wrote:

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

The Network-User Event header parameter MAY be set to
the AOR of the user.  In section 3.2 which talks about
the specifics of the Network-User parameter is states
that this parameter MAY be set for "device" or "local"
profile types.  Does this cover the use case you had
in mind?

_______________________________________________
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: "Daniel G. Petrie" <[email-masked]>
Date: Mon, 1 Nov 2004 14:29:06 -0800 (PST)

Sorry, I just realized that the latest draft has
not made it through the works to be announced yet.

In the mean time the updated draft can be downloaded
from:

html:
http://scm.sipfoundry.org/viewsvn/*checkout*/ietf-drafts/sipping/config-framework/config-framework.html?rev=235

txt:
http://scm.sipfoundry.org/viewsvn/*checkout*/ietf-drafts/sipping/config-framework/config-framework.txt?rev=235