Subject: [Sipping] Re: Config framework - issue with parameters send in Event header

From: "Daniel G. Petrie" <[email-masked]>
Date: Fri, 22 Oct 2004 17:52:01 -0400

Thanks for the comments.  I would like to hear opinions from
folks on the list on whether they think this is a current
requirement or not.

Thanks,
Dan

"Elwell, John" wrote:
> 
> Dan,
> 
> In reviewing the draft-ietf-sipping-config-framework-04, I noticed that
> several parameters had been defined for the Event header giving information
> about the device, i.e., "vendor", "model" and "version". I am concerned that
> these may not be sufficient in all cases for the profile delivery server to
> determine the precise profile to be delivered. Moreover, the profile
> delivery server may use these parameters to compile an inventory of devices
> for admin purposes, and more detailed information might be needed for this
> purpose, even if it does not influence the choice of profile to be
> delivered. Examples of extended information that might be considered useful
> for the profile delivery server are:
> 
> - where a particular UA model has different components, each with its own
> version number (e.g., hardware version and software version);
> - where a particular UA model has some optional extras, these may need to be
> listed together with their respective version numbers.
> 

I did not see any comments on this on the list.  Are there any opinions
out there?  I see no technical reasons against adding a components
parameter.  Components values can be a vendor scoped token. If there
is more than one component that the user agent wants to specify it
could add more than one "component" parameter each have a value of
a token.

My main reservation is the case for simplicity.  It is very easy to
add parameters in the future if we really need them.  Please speak
up if you think there is a case for defining this now.

> Has any consideration been given to providing an extensible mechanism for
> delivering UA information in a SUBSCRIBE request to a profile delivery
> server?
> 

Doesn't the Event header parameters construct provide this?  Do we need
something more specific to profile delivery?

> John Elwell ([email-masked])

_______________________________________________
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: Simonetti Gabrielle <[email-masked]>
Date: Tue, 26 Oct 2004 20:38:18 +0200

Providing the parameters in the body of the SUBSCRIBE is a good idea but would increase the load on the network, as well as require the definition of a new data schema for the SUBSCRIBE body. Why not use the User-Agent Header defined in RFC3261 to transport the information about the UA originating the request? It can contain several components together with their version number (e.g. the Nokia traditional User-Agent string used for HTTP: Nokia6600/ 1.0 (4.03.24) SymbianOS/ 6.1 Series60/ 2.0 Profile/ MIDP- 2.0 Configuration/ CLDC- 1.0). In this case, the order in which the information is set in the header is not specified, however the constructor would know how the UA forms the header and thus understand the subscribe request for the device profile. This header would have to be mandatory in the profile delivery requests.
Gabrielle

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Paul Kyzivat
> Sent: martedì 26 ottobre 2004 0.41
> To: Elwell, John
> Cc: 'Daniel G. Petrie'; [email-masked]'
> Subject: Re: [Sipping] RE: Config framework - issue with 
> parameters send
> inEvent header
> 
> 
> Did anyone consider providing these parameters as a body in the 
> SUBSCRIBE? (Something like a "filter" in a warped sort of way.)
> 
> 	Paul
> 
> Elwell, John wrote:
> > Dan,
> > 
> > In-line [JRE]
> > 
> > John ([email-masked]) 
> > 
> > -----Original Message-----
> > From: Daniel G. Petrie [mailto:[email-masked]] 
> > Sent: 22 October 2004 22:52
> > To: Elwell, John
> > Cc: [email-masked]'
> > Subject: Re: Config framework - issue with parameters send 
> in Event header
> > 
> >>several parameters had been defined for the Event header giving
> > 
> > information
> > 
> >>about the device, i.e., "vendor", "model" and "version". I 
> am concerned
> > 
> > that
> > 
> >>these may not be sufficient in all cases for the profile 
> delivery server
> > 
> > to
> > 
> >>delivery server may use these parameters to compile an inventory of
> > 
> > devices
> > 
> >>delivered. Examples of extended information that might be considered
> > 
> > useful
> > 
> >>- where a particular UA model has some optional extras, 
> these may need to
> > 
> > be
> > 
> > [JRE] I guess I am confused about the mechanism for adding 
> new Event header
> > parameters. Looking at RFC3265, there does not appear to be any IANA
> > registry for Event header parameters. Perhaps this is 
> intentional - perhaps
> > parameters are intended to be interpreted within the context of the
> > particular event package concerned.
> > Looking at the config framework, I don't see anything there 
> to register the
> > new parameters (vendor, model, etc.) - sorry I failed to 
> pick that up during
> > my review. However, even if the config framework were to 
> register these
> > parameters with IANA, it might require an update to the 
> config framework in
> > future to add new parameters unless, in creating the 
> registry, it allowed
> > other means to add new parameters. What I had in mind was 
> the ability for a
> > particular vendor to add further parameters according to 
> his needs. These
> > might be meaningful to a server from the same vendor or 
> would be silently
> > discarded if not recognised. So if there is not sufficient 
> interest in the
> > community for the "component" parameter, at least a 
> particular vendor could
> > define something similar.
> > 
> > 

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