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

From: "Elwell, John" <[email-masked]>
Date: Mon, 25 Oct 2004 14:06:58 +0100

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 25 Oct 2004 18:41:03 -0400

Did anyone consider providing these parameters as a body in the 
SUBSCRIBE? (Something like a "filter" in a warped sort of way.)

	Paul