Subject: [Sipping] Comments on draft-ietf-sipping-config-framework-06

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 05 Mar 2005 10:57:49 -0500

I would find it helpful if the draft in Section 2.3 actually referred to 
the sections where the stages are defined (e.g., enrollment). The draft 
leaves it up to the reader to surmise that 'discovery of subscription 
URI' is the same as 'Discovery' in the introduction.

Lots of details in the subscription get covered before any of the other 
steps are even outlined. To get a good feel for what the draft is about, 
I have to skip section 3, read section 4 and then maybe go back to 
section 3.

Generally, the draft seems biased towards hardware devices, presumably 
because of its origins. I would find it more helpful to have more 
discussion or explicit separation for the "download software" case where 
the user only goes to a web page, downloads a piece of software, signs 
up to get an account and gets the web page delivered. Ideally, the user 
should not have to type in anything except possibly the password.

I also found the discussion on authentication a bit terse. In my view, 
getting the authentication right is the hardest part, particularly for 
hard phones. How do you envision that a plain-vanilla phone out of the 
box authenticates itself to get a device profile? Having options is 
great, but I think it would help to explicitly describe, in one place, 
possible (informational) scenarios for the two most common cases - 
downloaded software (FreeWorldDialup or Skype model) and enterprise 
Ethernet phones. Having a worked-through example would help.

I would find it helpful to describe the simplest case, namely HTTPS 
retrieval, in more detail. I'd like to get this deployed quickly, 
without having to wait until everyone has implemented XCAP. (One can 
argue that XCAP is probably not needed if the device simply retrieves 
the configuration document and leaves profile changes to a web interface.)

The 'HTTPS-first' case seems underspecified for practical use. I guess 
there are really two cases: namely, the user clicks on a link in a 
browser, which retrieves the config document. To make this useful, the 
install process for the UA has to register the UA as the MIME handler 
for that document type. Obviously, this works only if the user has one 
SIP UA.

The second solution is to have the UA do the HTTPS retrieval, but then 
the user of a generic software UA is burdened to somehow figure out the 
URI for the configuration file. One simple solution is to use the Accept 
mechanism: By including Accept: application/*profile*
in the GET, the user could be told to just go to http://provider.com and 
the web server would recognize this as an enrollment request.

The third solution is to have the user install the software client 
first, have the installation register the application/sip-message MIME 
type (and, possibly, the sip: protocol handler) and then provide a data: 
or sip: link on the web page, which starts up the client and has it send 
the SUBSCRIBE request.

Since this whole effort is fundamentally about making the user 
experience better, we need to, I believe, provide more guidance to 
implementors, even if it is not normative. Otherwise, it is very 
unlikely that we'll meet the goal of allowing generic SIP clients to be 
used across service providers.

Henning

_______________________________________________
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