Subject: [Sipping] comments on draft-ietf-sipping-config-framework-07

From: Josh Littlefield <[email-masked]>
Date: Wed, 25 Jan 2006 01:28:05 -0500

I found some inconsistencies in draft-ietf-sipping-config-framework-07 
draft that the chairs have asked I bring up to the list to help expedite 
wrapping up the document.  In order or increasing significance, more or 
less:

1. This is a somewhat minor clarification issue.  The informative text 
in section 5.1, steps 6 and 7, says that the device could re-subscribe 
to the device profile using a different request URI than it originally 
had derived.  It isn't clear whether this URI would have to continue to 
have a MAC-based or UUID-based username part.  I'd suggest we clarify in 
section 5.1 step 6 that the learned device URI still has the required 
MAC/UUID form, but uses a different host portion.  Otherwise, we would 
need to change section 7.13.1 to indicate other forms of device URI are 
allowed as well.

I would suggest adding a line at the end of step 6 in section 5.1: "The 
new device profile URI should still conform to the requirements of 
section 7.13.1, but might differ in the host portion."

2. Sec. 7.2 says (right after ABNF of vendor, model and version), "The 
``network-user'' parameter SHOULD be set when subscribing for device and 
local network profiles..."  However, the table at the end of sec. 7.2 
shows "network-user" as a SHOULD for local-network, and not even 
optional for device profile.  I assume if this table is changed, both 
the SUBCRIBE and NOTIFY tables must match for this parameter (based on 
the text that says if network-user is in the subcribe, it must be in the 
notify).

I would suggest changing the SUBSCRIBE and NOTIFY tables at the end of 
sec. 7.2 to make the "network-user" parameter a "SHOULD" ("s") for 
device profiles.  Though perhaps it really needs to be something like 
"s/m" or "o/m" in the NOTIFY table, since it's really mandatory in the 
NOTIFY if provided in the SUBSCRIBE, and otherwise would not be in the 
NOTIFY at all.

3. I assume, though I'm don't read it as explicitly stated, that the 
"document" parameter in a SUBSCRIBE is only allowed to name one document 
(that is, it cannot be a list of multiple documents), and is only 
allowed to appear once in the Event header.  It is also not clear if the 
"document" parameter may refer to a directory of multiple documents 
instead of a single document.  The second SUBSCRIBE event header 
example, near the end of section 7.2, shows a document parameter that 
appears to name a directory (document="user-aor/").  I think the syntax 
and semantics of the document parameter need to be explicit.

Perhaps the number of occurrences of any parameter is already 
well-defined (though the BNF in 3261 and 3265 doesn't seem to answer 
this).  If not, then I'd suggest adding a sentence to the end of the 
first para. of sec. 7.2 which says, "Each parameter may occur only once 
in the Event header."

I'd suggest changing the first sentence of the paragraph describing the 
"document" parameter in sec. 7.2 to say, "The "document" parameter is 
used to specify a relative URI for a single specific profile document 
that the user agent wishes to retrieve and for which it wishes to 
receive change notification."  (Adding the word "single".)  As for 
whether the document parameter value can be a directory of documents, I 
think we should either make it explicit that this is always allowed, 
that it is never allowed, or that it is possible but depends on the 
profile data format definition.  It would seem least complex to say that 
it should refer to a document, not a directory (and the current text is 
pretty close to that), and then we should change the SUBSCRIBE example 
that uses "user-aor/" to use something else.

4. In sec. 8.6 there is an issue that was was brought up on the mailing 
list last September, but never resolved.  The description of XCAP paths 
is at odds with the XCAP I-D.  The first path component in a relative 
XCAP document selector would always be an AUID. Paths are 
"<AUID>/user/<XUI>/<doc>" or "<AUID>/global/<doc>".  However, the 
config-framework text claims the first component would be either 
"global" or "user" and this is eventually followed by an AUID.  I don't 
believe there is any intention to change XCAP, so this text needs to be 
fixed in the config-framework. This requires some re-working of sec. 8.6.

5. Toward the end of sec. 8.6 (the last SUBSCRIBE illustration at the 
bottom of page 32), the text implies that by subscribing with a specific 
auid, one ends up subscribing to a single global document, rather than a 
user-specific document.  I don't follow that logic.  I believe 
subscribing with a specific auid should result in a subscription to all 
"relevant" documents in the global and/or user-specific areas.

6. There is a lot of focus on content indirection, but when XCAP is 
used, this is inconvenient because the NOTIFY cannot communicate a new 
ETag value when using true content indirection.  Content indirection 
only comminicates contend-id to describe the document state, and the 
XCAP client can't easily learn a new content-id when changing a 
document.  (It also isn't clear to me that content indirection can 
easily describe multiple documents simultaneously, but maybe with 
multipart/mixed this can be done.)  I would add mention of XCAP Diff in 
some of the places where content indirection is mentioned in the 
document, especially the first paragraph of section 7.

7. The current document prohibits the setting both "auid" and "document" 
Event header parameters at the same time.  While I realize allowing this 
can lead to conflict if the "document" value implies an auid (first 
component of its path) at odds with the "auid".  However, I'll also note 
that OMA, in their XDM specification, has mandated non-conformance with 
this restriction.  I believe the issue is that routing of the SUBSCRIBE 
to different places based on a simple filter looking at "auid" is 
simpler than defining some routing based on "document", yet subscribing 
to a specific document can also be very useful.  I'd like to allow the 
auid and document parameters to be set simulaneously with the 
requirement that they be consistent (if the document value is implies an 
auid).

8. This last issue is not unrelated to one brought up recently by Walter 
Goix as to whether "auid" may be specified when XCAP is not being used. 
  The text regarding "auid" in the current document links it pretty 
closely with XCAP, but as mentioned above, it can be very useful for 
routing SUBSCRIBEs for different applications to the proper profile 
delivery server, even when XCAP will not be used for document delivery 
and management.  XCAP defines the AUID namespace to be an XCAP-oriented 
IANA registry, though there is also a syntax for vendor use.  I don't 
know if it's really proper to allocate AUIDs for non-XCAP purposes, but 
the alternative is to limit auid parameter usage to XCAP delivery, or to 
redefine the config-framework auid and manage an additional registry for 
config-framework auids.  Is there an easy middle ground?

-josh

-- 
=====================================================================
Josh Littlefield                                  Cisco Systems, Inc.
[email-masked]                             1414 Massachusetts Avenue
tel: 978-936-1379  fax: 978-936-2226       Boxborough, MA  01719-2205

_______________________________________________
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