Subject: [Sipping] Cullen's config package comments

From: Rohan Mahy <[email-masked]>
Date: Mon, 3 Jan 2005 15:04:55 -0800

Cullen raised some important meta issues about the config framework in 
his Dec 24th review. For the three major issues I list here, I don't 
think any normative changes are needed, just additional motivational 
text. Below are my interpretations:

1) Why is no mandatory to implement file format is specified?
Switching immediately to one file format for SIP User Agents is 
impractical. As mentioned briefly in the draft, even without a 
mandatory-to-implement file format, there is a tremendous benefit to 
have ONE MECHANISM for discovery and change notification.  The actual 
config file format can be proprietary as long as the subscriber 
includes the MIME type for this file format in its Accept header field. 
  This greatly improves the state of the art, where a different 
(potentially conflicting) TFTP or HTTP URL convention is used for each 
vendor and clients must poll or rely on proprietary mechanisms to force 
reboots or configuration refreshes.

2) The config framework does not specify a mandatory to implement 
scheme. Why is that OK?
- First of all the configuration framework should continue to work for 
clients that use TFTP now (especially if they are fetching encrypted 
files). When we have a standardized file format, I recommend that we 
require implementation of HTTP with hash checking and HTTPS as baseline 
mechanisms to transport the standardized file format.
- Cullen asked how does the notifier detect what schemes are acceptable 
to the user agent requesting configuration data.  The notifier can make 
this determination initially based on out-of-band configuration about 
the capabilities of the phone.  This is not a significant burden for a 
notifier handling proprietary file formats since the notifier probably 
needs to be configured with knowledge about how to parse one or more 
proprietary configuration file formats based on the make and model of 
the phone. If available, the notifier can also use capabilities 
included in the user agent's registration (using callee-caps) to 
determine which schemes are supported.
- That said, I do not object to making HTTPS and HTTP with hash 
checking RECOMMENDED for the client (subscriber), and MANDATORY for the 
server (notifier).

3) Why an algorithm for merging is not specified.
Merging is based on the assumption that the client asked for at least 
two data sets.  If the client never asks for multiple data sets, it 
does not have to merge anything.  If the client asks for multiple data 
sets it needs to understand how to read all the types in its Accept 
header and how to do a merge for those acceptable file formats.  The 
standardized format will specify some very simple merging rules.  For 
now, the framework standardizes the semantics and allows things to get 
better now before a file format is fully specified and universally 
deployed. [For those skeptics concerned if such a merging algorithm is 
implementable, Dan Petrie provided an existence proof in session during 
the DC meeting. I will let him explain this proposal separately.]

----

As for one of the smaller issues he raised, I agree that the instance 
SHOULD be a UUID.  There are many good reasons to do this, nobody has 
identified a reason NOT to do this, so we should be specific.  We are 
doing this for GRUU anyway.

thanks,
-rohan

_______________________________________________
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