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

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

Simonetti Gabrielle wrote:

> 
> > Section 4.6
> > ------------
> >
> > - This sentence:
> >    "When the "profile-name" is application, but the "app-id" parameter
> > is absent, this specifies that the user wishes to SUBSCRIBE to all
> > documents for all application usages associated with the user in the
> > request-uri."
> >
> > contradicts with this one:
> >
> > "If the "profile-name" is "application", the "app-id" MUST be present as well."
> >
> > The latter says its a MUST, but the former said the "app-id"
> > missing is feature.
> 
> Actually, it is not specified in the framework which of the Event Header parameters are obligatory/optional/unnecessary in a subscription. For example, I would imagine that for the "device" profile subscription, the parameter "vendor" is obligatory, while the parameters "model" and  "version" are optional (the parameter "vendor" alone in a subscription would correspond to the profile relative to all devices from one same vendor). On the opposite, for the "application" profile subscription, the "app-id" parameter could be obligatory while "vendor", "model" and "version" are unnecessary.

Wow.  Thanks, I will fix that.  It was intended that vendor, model and version
were manditory for all the profiles.  Though it may not be necessary, it is
potentially useful to the profile delivery server to know these parameters
should it desire to customize the profile based upon the specific implementation.
In the perfect world they will all be have the same.  However we are in a
real world and I think that it is important to give the profile delivery server
the ability to customize the profiles.  If we do not make these mandatory,
implementors will not put them and the profile delivery server will be
running blind.

app-id is supposed to be optional for application profiles to specify a 
single application profile as opposed to all application profiles.  It
is ignored for non-application profile types.

similarly document is optional for all profile types to specify a 
specific document or element.

> 
> Regards,
> 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

_______________________________________________
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 15:27:50 -0400

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.

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.

---

From: David R Oran <[email-masked]>
Date: Mon, 25 Oct 2004 11:52:33 -0400

On Oct 22, 2004, at 3:09 PM, Daniel G. Petrie wrote:
[snip]

>> Actually, it is not specified in the framework which of the Event 
>> Header parameters are obligatory/optional/unnecessary in a 
>> subscription. For example, I would imagine that for the "device" 
>> profile subscription, the parameter "vendor" is obligatory, while the 
>> parameters "model" and  "version" are optional (the parameter 
>> "vendor" alone in a subscription would correspond to the profile 
>> relative to all devices from one same vendor). On the opposite, for 
>> the "application" profile subscription, the "app-id" parameter could 
>> be obligatory while "vendor", "model" and "version" are unnecessary.
>
On the contrary, experience has shown that people use the presence of 
such information to "customize" their way to non-interoperability. I 
have no objection to including the implementation information because 
it helps both customization and debugging, but I suggest two things:
a) That these fields NOT be mandatory. I would be ok with SHOULD 
strength, as long as there is some kind of escape clause to cover 
ensuring anonymity of implementation where desired so that bad 
customizations can be avoided.
b) That the presence of these fields MUST not alter the operation of 
any configuration protocol machinery - it may only be used to customize 
the delivered data.

Dave.