Subject: Re: [Sipping] Comments on config framework draft- URIs andeventpackage parameters

From: "Daniel G. Petrie" <[email-masked]>
Date: Fri, 22 Oct 2004 16:06:09 -0400

Goix Walter wrote:
> 
> Inline
> 
> > > 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.
> 
> What about a URL pointing to a CC/PP XML profile to identify the device?
> Most of the times, such URLs already embed all "vendor", "model" and
> "version" information only looking at the HTTP address and without
> reading the actual XML content. Processing the content may provide
> further information for a device profile delivery server to identify the
> target of the subscription and apply its own rules to identify when that
> particular watcher/device should be notified.
> This would allow to remove (or put as optional) the fixed and limited
> set of parameters of the Event: header, and may also be reused in other
> subscriptions (local, user, app).
> 

I think that I would like to avoid introducing another set of
syntax from which to parse vendor, model and version.  I think
providing them as parameters is simpler.

_______________________________________________
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: Fri, 22 Oct 2004 16:27:44 -0400

Goix Walter wrote:

> > > Section 3.13.3
> > > --------------
> > >
> > > - about placing an "anonymous" user name. Why isn't
> > > sip:example.com enough (no user part)? If user part is
> > > present, it MUST be ignored.
> >
> > The instance-id might be useful here in the user part of the
> > "local" profile URI, in the case where the default local
> > parameters delivered by the modem depend on the device.
> 
> I agree. If we think at local domains as "home" and "visited"-types of
> domains, a "home" domain server may recognize a specific instance of a
> device as belonging to its own domain and configure it differently from
> another device in "roaming".

I think the capabilities provided or allowed by the local network
are more closely associated with the user than the device.  That is 
purpose of the optional network-user event parameter. The user's
identity is provided in the form of their AOR so that the network
has the option of providing capabilties specific to the user.

See also:
http://www.ietf.org/mail-archive/web/sipping/current/msg06982.html

> 
> Laurent-Walter Goix
> Telecom Italia - TILAB
> Service and Platform Innovation - Service Control Platforms
> 
> 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
> ====================================================================
>