Re: [Sip] Possible semantic confusion w/ bodies in subscribes

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 sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip