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

[Jari Urpalainen <[e-mail]>]

ext Adam Roach wrote:
> 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.
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.
>
>   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
> _______________________________________________
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


_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip