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

Dave Crocker <> Thu, 23 January 2014 03:00 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 726031A00D9; Wed, 22 Jan 2014 19:00:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tOVvLkQXHGSW; Wed, 22 Jan 2014 19:00:37 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B618F1A00AC; Wed, 22 Jan 2014 19:00:37 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id s0N30XaN005784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Jan 2014 19:00:36 -0800
Message-ID: <>
Date: Wed, 22 Jan 2014 19:00:16 -0800
From: Dave Crocker <>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Peter Saint-Andre <>, Apps Discuss <>,,
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 ( []); Wed, 22 Jan 2014 19:00:37 -0800 (PST)
Cc: iesg <>
Subject: Re: [Stox] Review of: draft-ietf-stox-presence-06
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 23 Jan 2014 03:00:39 -0000

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.


>>>     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.


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

ack. tnx.


Dave Crocker
Brandenburg InternetWorking