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

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

An earlier version of the config framework actually
proposed using the User-Agent header.  However the
User-Agent header is currently too syntactically
unconstrained to make the needed parameters parsable.
There were lots of groans from the audiance when this
was discussed and suggested that we should better
parameterize the Use-Agent header.

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

> 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
> > > 
> > > 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?
> > > [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
> 
=== message truncated ===

_______________________________________________
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