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

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 21 Jan 2014 16:57:16 +0100

Hi Peter,

when do you think you will get around to revising the draft per Dave's
comments?

Thanks for the review, Dave.

Cheers,

Gonzalo

On 17/12/2013 4:39 PM, Dave Crocker wrote:
> Only responded where it seems needed or useful...
> 
> 
> 
> On 12/13/2013 2:47 PM, Peter Saint-Andre wrote:
> 
>>>     1.  When citing the earlier efforts, there should be something to
>>> explain why the current work is expected to be more successful.
>>
>> Not "expected", but "is". :-) AFAIK there are no implementations of the
> 
> I'd missed that this is based on deployed work.  That is a point that
> always makes writing text justifying/motivating the document quite easy:
>  just say that.
> 
> 
>> approach taken by RFC 3922 and draft-ietf-simple-cpim-mapping (i.e.,
>> mapping to the abstract semantics of RFC 3860), whereas there are
>> multiple implementations of the approach described here (i.e., direct
>> mapping between SIP and XMPP).
>>
>>> That is,
>>> what makes the current approach notably tractable for implementation and
>>> deployment?
>>
>> Do you think that explaining why would improve the document? IMHO this
> 
> I'm a fan of context and systems views, because I think it orients the
> reader usefully, so the simple answer is yes.
> 
> Whenever there is a lengthy history with alternative efforts, readers
> can benefit from some context that distinguishes the current work.  Not
> in qualitative terms like better or worse, but in technical and
> operational terms.
> 
> Hence I think language like what's already in the document, that
> distinguishes the 'architectural' difference from earlier work, but also
> one that says that the current work is based on deployed industry choice.
> 
> 
>> verges into developer psychology (I've got this SIP thing here and this
> 
> 
>>>     5.  When showing protocol examples, usually only one side of the
>>> sequence is shown.  For gatewaying that does interesting transforms,
>>> such as this one, an example should show both the before and after
>>> versions.  That is, the 'native' protocol unit that was created and then
>>> the one that results from the translation.
>>
>> I thought we'd already done that. For instance, Example 2 is the SIP
>> transformation of the XMPP stanza shown in Example 1.
> 
> Either the document didn't do it as diligently as I'm suggesting, or I
> didn't understand this aspect of the document, which might be remedied
> by better labeling.
> 
> For any example that is done in a gateway and is a translation between
> sip presence and xmpp presence, something simple and rigorous, such as
> "before" and "after" labels to source and transformed versions, ought to
> remedy this.
> 
> 
> 
> 
>>> This probably raises a larger issue:  How much expertise is expected of
>>> someone who is implementing this or otherwise reading for deep
>>> comprehension?  In the extreme, they will need to have serious expertise
>>> on both protocol sets.  The other extreme would be a cookbook inside
>>> this document, with no outside knowledge required.  The document needs
>>> to specify the nature and extent of the expertise required.  (In fact,
>>> the document seems pretty clean, in terms of explaining things, so I
>>> suspect that 'fair' knowledge of one suite will suffice.  But the author
>>> and wg beliefs about the requirement should be made explicit.)
>>
>> See above. Perhaps not expert level, but significant familiarity with
>> one "side" or the other.
> 
> Just to emphasize, whatever the knowledge-level of reader that's
> required, the document should make that explicit.
> 
> I'm always a fan of making documents more accessible to wider
> readership, but it's not practical to make all documents fully
> accessible, especially within a suite of docs that build on each other.
> 
> 
>>>>     |  SUBSCRIBE sip:[email-masked] SIP/2.0
>>>
>>> Later text (section 4.1) equates the label pres: with sip: and sips:.
>>> Why choose sip: here?
>>
>> In practice, we don't see 'pres' URIs in the wild.
> 
> Hmmm.  While 'statistics' of use is a relatively fragile basis for
> putting things into a spec -- since a doc can last for decades and
> statistics can change -- it might be worth mentioning as the basis for
> the choice in the doc.  I suppose that's in the realm of giving the
> reader a bit of operational insight.  But definitely not an important
> point.
> 
> 
> 
>>>>     Example 3: SIP accepts subscription request:
>>>>
>>>>     |  SIP/2.0 200 OK
>>>>     |  Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKna998sk
>>>>     |  From: <sip:[email-masked]>;tag=ffd2
>>>>     |  To: <sip:[email-masked]>;tag=j89d
>>>>     |  Call-ID: 5BCF940D-793D-43F8-8972-218F7F4EAA8C
>>>>     |  CSeq: 234 SUBSCRIBE
>>>>     |  Contact: <sip:simple.example.net;transport=tcp>
>>>>     |  Expires: 3600
>>>>     |  Content-Length: 0
>>>
>>> Hmmm.  This appears to be the original SIP acceptance, but with no
>>> separate display of it's being translated into XMPP.
>>
>> That is Example 5.
> 
> Oh. It's worth making that explicit.  (My tendency to get confused
> reading specs is a useful canary in the tunnel, for what needs
> clarifying for other readers, IMO...)
> 
> 
> 
>>>>     Example 10: SIP user subscribes to XMPP contact:
>>>>
>>>>     |  SUBSCRIBE sip:[email-masked] SIP/2.0
>>>>     |  Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKna998sk
>>>>     |  From: <sip:[email-masked]>;tag=xfg9
>>>>     |  Call-ID: AA5A8BE5-CBB7-42B9-8181-6230012B1E11
>>>>     |  Event: presence
>>>>     |  Max-Forwards: 70
>>>>     |  CSeq: 263 SUBSCRIBE
>>>>     |  Contact: <sip:simple.example.net;transport=tcp>
>>>>     |  Accept: application/pidf+xml
>>>>     |  Content-Length: 0
>>>>
>>>>     Notice that the "Expires" header was not included in the SUBSCRIBE
>>>>     request; this means that the default value of 3600 (i.e., 3600
>>>>     seconds = 1 hour) applies.
>>>>
>>>>     Upon receiving the SUBSCRIBE, the SIP server needs to determine the
>>>>     identity of the domain portion of the Request-URI or To header,
>>>> which
>>>>     it does by following the procedures discussed in
>>>>     [I-D.ietf-stox-core].  Here we assume that the SIP server has
>>>>     determined that the domain is serviced by an XMPP server, that it
>>>
>>>
>>> This seems to mean that a regular SIP server needs to be familiar with
>>> technical details in a gatewaying specification??
>>
>> Well, it is (IMHO) really the responsibility of a core "server" to
>> implement this kind of routing functionality, but the "gateway" might
>> make the determination that the remote domain uses SIP or XMPP and if
>> SIP then pass it on to the SIP "server" and if not handle delivery to
> 
> I think this matches the usual model:  an unchanged server does routing
> as if all participants were part of its 'native' protocol service.  A
> gateway translates and tries to hide any differences between two services.
> 
> The current doc language seems confusing on this point, when it talks
> about a (native) server choosing a server that is part of the other
> service.
> 
> This is a sufficiently basic point to probably warrant going into -core,
> rather than here.  But the language here probably therefore ought to
> just be in terms of originators and recipients (or whatever generic
> terminology works for presence) with an initial, simple note that
> knowledge of the need for translation only resides in the gateway(s).
> 
> But I'm not sure I mentioned another point that confused me from -core:
>  It shows the two types of gateways as talking to each other, but I
> suspect that's not reality.  FOr example, when doing SIP-XMPP, I suspect
> the actual flow is:
> 
>    SIP User
>    SIP Server
>    SIP-XMPP Server
>    XMPP Server
>    XMPP User
> 
> whereas the implication from the -core diagram and some of the language
> in the spec(s) is:
> 
>    SIP User
>    SIP Server
>    SIP-XMPP Server
>    XMPP-SIP Server
>    XMPP Server
>    XMPP Use
> 
> If it really is the later sequence, I don't understand why.
> 
> 
> 
>> the remote XMPP domain. To some extent it's a matter of implementation
>> where exactly the code lives to complete these functions, which is why
>> draft-ietf-stox-core talks about a "SIP service" consisting of both a
>> SIP "server" and a "gateway". In XMPP this translation function is often
>> handled by what we call a "connection manager", but that depends a bit
>> on the internal architecture of the overall "service".
> 
> This point highlights the essential difference between a "networking
> architecture" and an "implementation architecture".
> 
> Mapping from the first to the second often permits very wide variations.
>  The former concerns distinct functionality that /can/ be distributed,
> where the latter makes specific choices for what /is/ distributed.
> 
> 
> 
> 
>>>>     As described in [RFC3856], presence information about an entity is
>>>>     communicated by means of a SIP NOTIFY event sent from a SIP user
>>>>     agent to an intended recipient who is most generally referenced
>>>> by an
>>>>     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>.  Here again we introduce the simplifying
>>>>     assumption that the user agent is controlled by a human user.
>>>
>>> I guess I'm not understanding how the nature of what is controlling the
>>> agent affects anything in this document.  Might be worth explaining
>>> that.
>>
>> A "presentity" doesn't have to be a human -- it could be a bot, a
>> device, or some other automated entity. People related more to human
>> users.
> 
> Sure, but when reading the doc, it felt as if the reference to this
> issue was relevant to functionality.  I'd expect the issue to be raised
> once in an Intro and then avoided later by use of a neutral term like
> user or presentity or whatever.
> 
> 
> 
>>>>     Note the following regarding these mappings:
>>>>
>>>>     1.  Only a presence stanza that lacks a 'type' attribute or whose
>>>
>>>     presence -> XMPP presence
>>
>> Stanzas are an XMPP artifact. But yes.
> 
> Choosing the level of semantic redundancy in the language is always a
> balancing act.  In a gatewaying document that will be reader by folks
> likely to be expert in only one half of the necessary technologies, I'd
> be inclined towards more redundancy, to reduce likelihood of
> misunderstanding...
> 
> 
> 
>>>>         'type' attribute has a value of "unavailable" SHOULD be
>>>> mapped by
>>>>         an XMPP-SIMPLE gateway to a SIP NOTIFY request, since those are
>>>>         the only presence stanzas that represent notifications.
>>>>     2.  The PIDF schema defines the tuple 'id' attribute as having a
>>>>         datatype of "xs:ID"; because this datatype is more restrictive
>>>>         than the "xs:string" datatype for XMPP resourceparts (in
>>>>         particular, a number is not allowed as the first character
>>>> of an
>>>>         ID), it is RECOMMENDED to prepend the resourcepart with
>>>> "ID-" or
>>>>         some other alphabetic string when mapping from XMPP to SIP.
>>>>     3.  This mapping is OPTIONAL.
>>>
>>> What does that mean?  This sort of mapping is usually the essence of
>>> gatewaying semantics.  How can interoperability tolerate it's being
>>> optional?
>>
>> In XMPP, the 'id' attribute is not usually included in presence stanzas,
>> and nothing is lost if it's ignored. But I'll give it a bit more thought.
>>
>>>> 4.3.  SIP to XMPP
>>>>
>>>>     When Romeo changes his presence, his SIP user agent generates a SIP
>>>
>>> Romeo is doing SIP?  And Juliet does XMPP?
>>
>> You noticed, eh? "Juliet does Jabber" makes it easy to remember, at
>> least for me.
> 
> So why isn't the other side Steve or Sid or...
> 
> Nevermind...
> 
> 
> 
>>> So, SIP is more macho than XMPP???
>>
>> Have you configured a SIP client lately? ;-)
>>
>> But seriously, the Romeo and Juliet scenarios enable me to use a male
> 
> The word seriously is entirely out of scope for this segment.  Or at
> least, it certainly was when I started it...
> 
> d/
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 22 Jan 2014 19:38:14 -0700

Hi Dave, sorry about the delayed processing of your feedback. Life has
gotten in the way here.

Further comments and proposed text inline.

On 12/13/2013 03:47 PM, Peter Saint-Andre wrote:
> Hi Dave, thank you for the review. Comments inline. I have not yet
> proposed text for the issues you raise, because that will take more time.
> 
> On 12/11/13 10:34 PM, Dave Crocker wrote:
>>
>> G'day.
>>
>> I have been selected as the Applications Area Review Team reviewer for
>> this draft (for background on apps-review, please see
>> http://www.apps.ietf.org/content/applications-area-review-team).
>> Please resolve these comments along with any other Last Call comments
>> you may receive. Please wait for direction from your document shepherd
>> or AD before posting a new version of the draft.
>>
>>
>>
>> Review of:    Interworking between the Session Initiation Protocol (SIP)
>> and the
>>               Extensible Messaging and Presence Protocol (XMPP): Presence
>> I-D:          draft-ietf-stox-presence-06
>>
>> Reviewer:     D. Crocker
>> Review date:  12 Dec 13
>>
>>
>>
>> Summary:
>>
>> XMPP and SIP both have deployed versions of instant messaging and
>> presence.  The current draft is part of a set of specifications that
>> define a gateway capability between the the two services.  In
>> particular, the current draft specifies the translation mechanism
>> between the presence mechanisms used by SIP and XMPP.
>>
>> The draft is well-structured and the text is mostly clear.  For an
>> implementer already familiar with the details of the two services and
>> the basics of the gatewaying specified here, the document probably is
>> sufficient -- although responses to some of the detailed comments,
>> below, might to turn out to show that a bit more work is needed. However
>> at the most, any technical improvements that might be needed will be
>> minor.  And I expect these to more in the nature of clarifying language
>> than of changing bits over the wire.
>>
>> However for a reader who is new to the topic, the document needs to be
>> clearer and sometimes more complete.
>>
>> Specific changes or concerns:
>>
> XMPP thing there, let me see how I can make them work as easily as
> possible without venturing off into abstract semantic stuff).

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.

See also http://tools.ietf.org/rfcdiff?url2=draft-ietf-stox-core-09.txt
for relevant changes to the "core" STOX document.

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

>>    3.  Saying that terms are taken from a substantial number of other
>> documents, and then merely citing the documents in their entirety, is
>> not helpful to the reader, unless the reader is required to be deeply
>> familiar with those documents. 
> 
> I do think it's required.

See text posted above.

>> If that's what this document requires,
>> say that.  If it's not, I suggest listing terms explicitly and
>> indicating what document they are drawn from.
>>
>>    4.  As the architecture diagram in Section 3 of stox-core shows, this
>> service has at least separate actors Actually I think it actually has at
>> least 6, which that diagram probably should show explicitly.  The six are:
>>
>>        a. SIP user
>>        b. SIP server
>>        c. SIP-XMPP gateway
>>        d. XMPP-SIP gateway
>>        e. XMPP server
>>        f. XMPP user
>>
>>        In any event, the specification needs to be very diligent to
>> carefully identify each actor involved in an activity and the
>> interaction between actors.  The current document uses language that
>> often left me wondering such things as who was the target of the action.
>>
>>        Much of this would be aided by some form of protocol sequence
>> diagrams, to show who does what and in what order.
> 
> I'll review the document again with these comments in mind. Your
> suggestion of sequence diagrams is a good one.

I've added sequence diagrams.

> transformation of the XMPP stanza shown in Example 1.

I've made the example descriptions a bit clearer in this regard.

>> Detailed Comments:
>>
>>
>>> Table of Contents
>>
>>
>> Nicely organized and concise TOC [ie, document structure).
>>
>>
>>
>>> 1.  Introduction
>> ...
>>>    One approach to helping ensure interworking between these protocols
>>>    is to map each protocol to the abstract semantics described in
>>>    [RFC3860]; that is the approach taken by both [RFC3922] and
>>>    [I-D.ietf-simple-cpim-mapping].  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).
>>
>> This begs the obvious question:  Why?  What was wrong with the previous
>> approach?
> 
> No one implemented it. The running code all takes the direct gatewaying
> approach.
> 
>> The purpose of the question is not for criticizing prior work but to
>> understand the expected benefit of the approach taken in the current
>> work.  What are the function, or OA&M differences produced through this
>> new approach, that are expected to be helpful?
> 
> These documents describe what people do in the field, what works and
> what doesn't, etc. We're not saying that other approaches are bad or
> infeasible.

See previous note.

>>>    The architectural assumptions underlying such direct mappings are
>>>    provided in [I-D.ietf-stox-core], including mapping of addresses and
>>>    error conditions.  The mappings specified in this document cover
>>>    basic presence functionality.  Mapping of more advanced functionality
>>>    (e.g., so-called "rich presence") is out of scope for this document.
>>>
>>>    SIP and XMPP differ significantly in their presence subscription
>>>    models, since SIP subscriptions are short-lived (requiring relatively
>>>    frequent refreshes even during a presence session) whereas XMPP
>>>    subscriptions last across presence sessions until they are explicitly
>>>    cancelled.  This document provides suggestions for bridging the gap
>>>    between these very different models.
>>>
>>>
>>> 2.  Terminology
>>>
>>>    A number of terms used here are explained in [RFC3261], [RFC3856],
>>>    [RFC6120], and [RFC6121].
>>
>> This sentence probably implies that the current draft should not be read
>> in the absence of familiarity with all 4 of those RFCs.  I suggest some
>> sort of explicit statement about how much prior knowledge is needed for
>> understanding the current draft, and where to get that knowledge.
> 
> Agreed.

See note above about the new Section 2.

>> In purely mechanical terms, the problem with the above sentence is that
>> it means that when the reader sees a term they don't understand, they
>> have to run around to four different documents looking for definitions.
>>  This mostly ensures reader frustration, for everyone but experts.
>>
>> The cleanest fix for this is to list terms and where they are defined.
>> The other, usual fix is to indeed say that the reader must be familiar
>> with those other documents before reading this one.  (sigh.)
> 
> I think these documents are for experts. In all likelihood, members of
> the target audience already have a SIP implementation and need to
> connect it to the XMPP network, or vice-versa. I don't think someone who
> is not familiar with either SIP or XMPP (or both) is going to hack up a
> gateway. There are much more rewarding tasks one might choose.
> 
> To your point, we need to say that.
> 
>>> 3.1.  Overview
>> ...
>>>    As described in [RFC6121], XMPP presence subscriptions are managed
>>>    using XMPP presence stanzas of type "subscribe", "subscribed",
>>>    "unsubscribe", and "unsubscribed".  The main subscription states are
>>>    "none" (neither the user nor the contact is subscribed to the other's
>>>    presence information), "from" (the user has a subscription from the
>>>    contact), "to" (the user has a subscription to the contact's presence
>>>    information), and "both" (both user and contact are subscribed to
>>>    each other's presence information).
>>
>> Nit:  for technical documents, lists like the above should be shown in
>> list format.  It really does help for quick comprehension.
> 
> Will fix.

Done.

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

[much text snipped where we have areas of agreement]

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

Peter

---

From: Dave Crocker <[email-masked]>
Date: Wed, 22 Jan 2014 19:00:16 -0800

>     existing systems solve the interworking problem.

wfm.

>     o  SIP-Specific Event Notification [RFC6665]

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

>     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