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