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

From: "Elwell, John" <[email-masked]>
Date: Tue, 26 Oct 2004 08:12:27 +0100

Paul,

I guess that is what I had in the back of my mind - why header parameters
and why not an XML body.

John

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Paul Kyzivat
Sent: 25 October 2004 23:41
To: Elwell, John
Cc: 'Daniel G. Petrie'; [email-masked]'
Subject: Re: [Sipping] RE: Config framework - issue with parameters send in
Event 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
> define something similar.
> 
> 
>>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
> 

_______________________________________________
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