Subject: RE: [Sipping] Re: Config framework - issue with parameters send inEvent header

From: [email-masked]
Date: Fri, 29 Oct 2004 12:50:22 +0300

I think this is stretching the scope of this draft a little. We can do without them for now.

/Hisham

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of ext Daniel G. Petrie
> Sent: 23.October.2004 00:52
> To: Elwell, John
> Cc: [email-masked]'
> Subject: [Sipping] Re: Config framework - issue with parameters send
> inEvent 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?
> 
> > 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