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

Dave Crocker <dhc@dcrocker.net> Thu, 23 January 2014 03:00 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 726031A00D9; Wed, 22 Jan 2014 19:00:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOVvLkQXHGSW; Wed, 22 Jan 2014 19:00:37 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id B618F1A00AC; Wed, 22 Jan 2014 19:00:37 -0800 (PST)
Received: from [192.168.200.211] (rrcs-74-62-19-234.west.biz.rr.com [74.62.19.234]) (authenticated bits=0) by sbh17.songbird.com (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: <52E085C0.5060202@dcrocker.net>
Date: Wed, 22 Jan 2014 19:00:16 -0800
From: Dave Crocker <dhc@dcrocker.net>
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 <stpeter@stpeter.im>, Apps Discuss <apps-discuss@ietf.org>, draft-ietf-stox-presence.all@tools.ietf.org, stox@ietf.org
References: <52A94AF6.8090702@dcrocker.net> <52AB8E69.7070906@stpeter.im> <52E08096.5070307@stpeter.im>
In-Reply-To: <52E08096.5070307@stpeter.im>
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 (sbh17.songbird.com [72.52.113.66]); Wed, 22 Jan 2014 19:00:37 -0800 (PST)
Cc: iesg <iesg@ietf.org>
Subject: Re: [Stox] Review of: draft-ietf-stox-presence-06
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=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.

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