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

From: Adam Roach <[email-masked]>
Date: Wed, 02 Jul 2008 12:51:07 -0500

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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Jari Urpalainen <[email-masked]>
Date: Thu, 10 Jul 2008 11:25:41 +0300

ext Adam Roach wrote:
>> I think we may have created some ambiguity here. If I'm wrong and 
>> it's clear, where is it captured in the documents? 
>
> 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.
>
I'll disagree here, why would  xcap-diff need Content-Disposition header 
? There's no ambiguity here since the "recipient-list" uniquely selects 
the right body from the uri-list-services multipart subscription. I 
think it has been made quite clear in the xcap-diff event i-d that it 
describes the very basic stuff (which is indeed quite complex already), 
so if there's need for some more, they can be added in extension specs, 
but imo this doesn't need any additional information.
> Comments on the proposed solutions -- and the draft in particular -- 
> are appreciated.
>
> /a
I'm basically fine with the i-d proposal although there are indeed quite 
many obstacles before it can be utilized in real-life: e.g. credential 
distributions, how to do conditional subscriptions, diff-processing 
changes may cause a lot of unnecessary traffic, and you really need not 
to loose any events etc. So all of this needs probably some 
explanation... So personally i don't see much benefit of implementing 
this for xcap-diff.

I'll have some editorial comments though, first remove all following 
declarations
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" from any example 
xml documents.

Regarding TODO note in 2.2: you can't really define that the cid 
attribute concerns the <entry> element, it is something one of those 
annoying features of the schema tool, so basically the schema is fine, 
it defines a single _qualified_ attribute (one of those things that i 
personally really dislike, too much ugliness  with additional namespace 
declarations, but here it is required because of the chosen extension  
model of the resource-lists format)

br, Jari