Re: [Stox] Review of: draft-ietf-stox-presence-06

[Dave Crocker <[e-mail]>]

On 1/22/2014 6:38 PM, Peter Saint-Andre wrote:
> Text adjusted to read:
>
>     One approach to helping ensure interworking between these protocols
>     is to map each protocol to the abstract semantics described in
>     [RFC3860]; although that is the approach taken by both [RFC3922] and
>     [I-D.ietf-simple-cpim-mapping], to the best of our knowledge that
>     approach has never been implemented.  The approach taken in this
>     document is to directly map semantics from one protocol to another
>     (i.e., from SIP/SIMPLE to XMPP and vice-versa), since that is how
>     existing systems solve the interworking problem.

wfm.



>>>     2.  The document is not clear about the prerequisites for reading
>>> this draft.  What must the reader already know in depth?  What must they
>>> have at least superficial knowledge of?  I suspect that, in particular,
>>> they need deep familiarity with stox-core.
>>
>> At the very least. Also RFC 3261, RFC 3856, RFC 6120, and RFC 6121.
>> (Note: the total page count of those RFCs is 621.) The specifications
>> normatively referenced by RFC 3856 are also relevant.
>
> Added the following section:
>
> 2.  Intended Audience
>
>     The documents in this series are intended for use by software
>     developers who have an existing system based on one of these
>     technologies (e.g., SIP), and would like to enable communication from
>     that existing system to systems based on the other technology (e.g.,
>     XMPP).  We assume that readers are familiar with the core
>     specifications for both SIP [RFC3261] and XMPP [RFC6120], with the
>     base document for this series [I-D.ietf-stox-core], and with the
>     following presence-related specifications:
>
>     o  A Presence Event Package for the Session Initiation Protocol
>        [RFC3856]
>
>     o  Presence Information Data Format (PIDF) [RFC3863]
>
>     o  Extensible Messaging and Presence Protocol: Instant Messaging and
>        Presence [RFC6121]
>
>     o  SIP-Specific Event Notification [RFC6665]

Well, that's certainly clear and thorough... if onerous.  But yeah, 
probably right.




>>>>     As described in [RFC3856], SIP presence subscriptions are managed
>>>>     through the use of SIP SUBSCRIBE events sent from a SIP user agent to
>>>>     an intended recipient who is most generally referenced by a Presence
>>>>     URI of the form <pres:user@domain> but who might be referenced by a
>>>>     SIP or SIPS URI of the form <sip:user@domain> or <sips:user@domain>.
>>>>
>>>>     The subscription models underlying XMPP and SIP are quite different.
>>>>     For instance, XMPP presence subscriptions are long-lived (indeed
>>>>     permanent if not explicitly cancelled), whereas SIP presence
>>>>     subscriptions are short-lived (the default time-to-live of a SIP
>>>>     presence subscription is 3600 seconds, as specified in Section 6.4 of
>>>>     [RFC3856]).  These differences are addressed below.
>>>
>>> The text that follows this 'addresses' the differences in terms of
>>> specifying how to handle specific differences.
>>>
>>> What's missing -- but I think would aid for the framework of this
>>> document's effort -- is for the above "For instance" to instead be
>>> expanded into a detailed statement of what the differences are, separate
>>> from the later text that says how to deal with the differences.
>>
>> That "for instance" is the main thing, so you're right that it needs to
>> be described in more detail.
>
> Changed to:
>
>     The subscription models underlying XMPP and SIP differ mainly in the
>     fact that XMPP presence subscriptions are long-lived (indeed
>     permanent if not explicitly cancelled, so that a subscription need
>     never be refreshed during any given presence "session"), whereas SIP
>     presence subscriptions are short-lived (the default time-to-live of a
>     SIP presence subscription is 3600 seconds, as specified in
>     Section 6.4 of [RFC3856], so that a subscription needs to be
>     explicitly refreshed if it will have the appearance of being
>     permanent or even of lasting as for the duration of a presence
>     "session").  This disparity has implications for the handling of
>     subscription cancellations in either direction and, from the SIP
>     side, subscription refreshes.

wfm.

> Thanks again for the review! I'll post a revised I-D soon.

ack. tnx.

d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net