On 6/30/08 1:15 PM, Robert Sparks wrote:
All (but particularly Jari and Adam) :
What does the body of a request mean if you get a SUBSCRIBE to the
"xcap-diff" event, and that subscribe
contains a Require: recipient-list-subscribe ?
I think we may have created some ambiguity here. If I'm wrong and it's
clear, where is it captured in the documents?
This line of questioning actually touches on two different issues --
disambiguation between the bodies of ad-hoc subscriptions and XCAP diff
subscriptions, and conveying XCAP diff subscriptions in ad-hoc lists. In
response to Robert's query, I'm proposing a set of actions to address
both cases.
1. The draft-ietf-sipping-uri-services document (which forms the
basis for the ad-hoc SUBSCRIBE list usage Robert is referring to
above) includes a Content-Disposition field that must be set to
"recipient-list" for the various ad-hoc list uses. This should be
sufficient to disambiguate between ad-hoc list usage and XCAP diff
subscriptions.
* For the purpose of clarity (and, coincidentally, to address
an IESG comment), we will be updating the definition of the
"recipient-list" content disposition to read: "The body
contains a list of URIs to which URI-List Services are to be
applied."
* For additional clarity and some level of consistency, I
would *STRONGLY* recommend that the XCAP diff event package
define a "Content-Disposition" field specific to its use of
the "application/resource-lists+xml" MIME type.
2. Although this answer ("use Content-Disposition") addresses the
ambiguity that Robert had been worried about, it doesn't address
the implied question about how one combines ad-hoc list usage with
XCAP diff subscriptions. In fact, this can be generalized to:
"when using ad-hoc list subscriptions, how does one convey the
information that would usually go in the SUBSCRIBE bodies?" This
is something we didn't actually consider in
draft-ietf-sip-uri-list-subscribe. To address this issue, I have
put together a proposal for conveying this information in ad-hoc
list subscriptions:
<http://www.ietf.org/internet-drafts/draft-roach-sip-list-subscribe-bodies-00.txt>
Comments on the proposed solutions -- and the draft in particular -- are
appreciated.
/a
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
