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

From: Dave Crocker <[email-masked]>
Date: Wed, 11 Dec 2013 21:34:46 -0800

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:

    1.  When citing the earlier efforts, there should be something to 
explain why the current work is expected to be more successful. That is, 
what makes the current approach notably tractable for implementation and 
deployment?

    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.

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

    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.

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?

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?

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

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

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

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

Someone needing to implement this spec, probably will be starting with a 
reasonable model of one side -- or at least, reasonable knowledge of the 
details, if not a thoughtful, higher-level model -- and considerable 
ignorance of the other. Text that discusses details of differences, 
distinct from how to resolve them, will put the implementer into a 
better position of understanding what's being done.

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

> 3.2.  XMPP to SIP
>
> 3.2.1.  Establishing a Presence Subscription
>
>    An XMPP user (e.g., [email-masked]) initiates a subscription by
>    sending a subscription request to another entity (e.g.,
>    [email-masked]), and the other entity (conventionally called a

Move definition of contact up to first occurrence, above.

>    "contact") either accepts or declines the request.  If the contact
>    accepts the request, the user will have a subscription to the
>    contact's presence information until (1) the user unsubscribes or (2)
>    the contact cancels the subscription.  The subscription request is
>    encapsulated in a presence stanza of type "subscribe":
>
>
>
>
> Saint-Andre, et al.      Expires April 21, 2014                 [Page 4]
> 
> Internet-Draft       SIP-XMPP Interworking: Presence        October 2013
>
>
>    Example 1: XMPP user subscribes to SIP contact:
>
>    |  <presence from=[email-masked]'
>    |            to=[email-masked]'
>    |            type='subscribe'/>
>
>    Upon receiving such a presence stanza, the XMPP server to which
>    Juliet has connected needs to determine the identity of the
>    domainpart in the 'to' address, which it does by following the
>    procedures discussed in [I-D.ietf-stox-core].  Here we assume that

Unfortunately, given the context of a citation like this, it really 
needs much greater precision, to point the reader to the exact portion 
of the document that is relevant to this context.

Unless, of course, the premise of the current document is that the 
reader must be deeply familiar with the -core document.  In which case, 
/that's/ what should be specified early in this document.  Based on what 
follows, I fear that indeed, this document requires deep familiarity 
with -core.

>    the XMPP server has determined the domain is serviced by a SIMPLE
>    server, that it contains or has available to it an XMPP-SIMPLE
>    gateway or connection manager (which enables it to speak natively to
>    SIMPLE servers), and that it hands off the presence stanza to the
>    XMPP-SIMPLE gateway.
>
>    The XMPP-SIMPLE gateway is then responsible for translating the XMPP
>    subscription request into a SIP SUBSCRIBE request from the XMPP user
>    to the SIP user:
>
>    Example 2: XMPP user subscribes to SIP contact (SIP transformation):

It took a moment to decide whether I was looking at XMPP form or SIP 
form.  Perhaps a more helpufl title for the example would be something like:

      Example 2: Translation of XMPP user's subscription request into SIP

>    |  SUBSCRIBE sip:[email-masked] SIP/2.0

Later text (section 4.1) equates the label pres: with sip: and sips:. 
Why choose sip: here?

>    |  Via: SIP/2.0/TCP x2s.example.com;branch=z9hG4bKna998sk
>    |  From: <sip:[email-masked]>;tag=ffd2
>    |  Call-ID: 5BCF940D-793D-43F8-8972-218F7F4EAA8C
>    |  Event: presence
>    |  Max-Forwards: 70
>    |  CSeq: 123 SUBSCRIBE
>    |  Contact: <sip:x2s.example.com;transport=tcp>
>    |  Accept: application/pidf+xml
>    |  Expires: 3600
>    |  Content-Length: 0
>
>    The SIP user then SHOULD send a response indicating acceptance of the
>    subscription request:
>
>    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.

>
> Saint-Andre, et al.      Expires April 21, 2014                 [Page 5]
> 
> Internet-Draft       SIP-XMPP Interworking: Presence        October 2013
>
>
>    In accordance with [RFC6665], the XMPP-SIMPLE gateway SHOULD consider
>    the subscription state to be "neutral" until it receives a NOTIFY
>    message.  Therefore the SIP user or SIP-XMPP gateway at the SIP
>    user's domain SHOULD immediately send a NOTIFY message containing a
>    "Subscription-State" header whose value contains the string "active"
>    (see Section 4).
>
>    Example 4: SIP user sends presence notification:
>
>    |  NOTIFY sip:192.0.2.1 SIP/2.0
>    |  Via: SIP/2.0/TCP simple.example.net;branch=z9hG4bKna998sk
>    |  From: <sip:[email-masked]>;tag=yt66
>    |  To: <sip:[email-masked]>;tag=bi54
>    |  Call-ID: 5BCF940D-793D-43F8-8972-218F7F4EAA8C
>    |  Event: presence
>    |  Subscription-State: active;expires=499
>    |  Max-Forwards: 70
>    |  CSeq: 8775 NOTIFY
>    |  Contact: <sip:simple.example.net;transport=tcp>
>    |  Content-Type: application/pidf+xml
>    |  Content-Length: 193
>    |
>    |  <?xml version='1.0' encoding='UTF-8'?>
>    |  <presence xmlns='urn:ietf:params:xml:ns:pidf'
>    |            entity='pres:[email-masked]'>
>    |    <tuple id='ID-orchard'>
>    |      <status>
>    |        <basic>open</basic>
>    |        <show xmlns='jabber:client'>away</show>
>    |      </status>
>    |    </tuple>
>    |  </presence>

Where is the xmpp translation of this?

>    In response, the SIMPLE-XMPP gateway would send a 200 OK (not shown

Sent it to whom?  (I probably know the answer, but the reader shouldn't 
have to guess; this is a spec.)

>    here since it is not translated into an XMPP stanza).
>
>    Upon receiving the first NOTIFY with a subscription state of active,
>    the XMPP-SIMPLE gateway MUST generate a presence stanza of type
>    "subscribed":
>
>    Example 5: XMPP user receives acknowledgement from SIP contact:
>
>    |  <presence from=[email-masked]'
>    |            to=[email-masked]'
>    |            type='subscribed'/>
>
>    As described under Section 4, the gateway MUST also generate a
>    presence notification to the XMPP user:
>
>
> Saint-Andre, et al.      Expires April 21, 2014                 [Page 6]
> 
> Internet-Draft       SIP-XMPP Interworking: Presence        October 2013
>
>
>    Example 6: XMPP user receives presence notification from SIP contact:
>
>    |  <presence from=[email-masked]/orchard'
>    |            to=[email-masked]'/>

This sequence feels like it should have a protocol sequence diagram, of 
the type used in rfc5263.

> 3.2.3.  Cancelling a Presence Subscription
>
>    At any time after subscribing, the XMPP user can unsubscribe from the
>    contact's presence.  This is done by sending a presence stanza of
>    type "unsubscribe":
>
>    Example 7: XMPP user unsubscribes from SIP contact:
>
>    |  <presence from=[email-masked]'
>    |            to=[email-masked]'
>    |            type='unsubscribe'/>
>
>    The XMPP-SIMPLE gateway is responsible for translating the
>    unsubscribe command into a SIP SUBSCRIBE request with the "Expires"
>    header set to a value of zero:
>
>    Example 8: XMPP user unsubscribes from SIP contact (SIP
>    transformation):
>
>    |  SUBSCRIBE sip:[email-masked] SIP/2.0
>    |  Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKna998sk
>    |  From: <sip:[email-masked]>;tag=j89d
>    |  Call-ID: 9D9F00DF-FCA9-4E7E-B970-80B638D5218A
>    |  Event: presence
>    |  Max-Forwards: 70
>    |  CSeq: 789 SUBSCRIBE
>    |  Contact: <sip:x2s.example.com;transport=tcp>
>    |  Accept: application/pidf+xml
>    |  Expires: 0
>    |  Content-Length: 0
>
>
>
> Saint-Andre, et al.      Expires April 21, 2014                 [Page 7]
> 
> Internet-Draft       SIP-XMPP Interworking: Presence        October 2013
>
>
>    Upon sending the transformed unsubscribe, the XMPP-SIMPLE gateway
>    SHOULD send a presence stanza of type "unsubscribed" to the XMPP
>    user:
>
>    Example 9: XMPP user receives unsubscribed notification:
>
>    |  <presence from=[email-masked]'
>    |            to=[email-masked]'
>    |            type='unsubscribed'/>

One of the advantages of showing sequences like these in a protocol 
sequence diagram is that it concisely shows which of the 4 actors does 
what and when.  Being able to see visual summaries like that will make 
the life of an implementer /much/ easier.

> 3.3.  SIP to XMPP
>
> 3.3.1.  Establishing a Presence Subscription
>
>    A SIP user initiates a subscription to a contact's presence
>    information by sending a SIP SUBSCRIBE request to the contact.  The
>    following is an example of such a request:
>
>    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??

>    Example 11: SIP user subscribes to XMPP contact (XMPP
>    transformation):
>
>    |  <presence from=[email-masked]'
>    |            to=[email-masked]'
>    |            type='subscribe'/>
>
>    In accordance with [RFC6121], the XMPP user's server MUST deliver the
>    presence subscription request to the XMPP user (or, if a subscription
>    already exists in the XMPP user's roster, send a presence stanza of
>    type 'subscribed').
>
>    If the XMPP user approves the subscription request, the XMPP server
>    then MUST return a presence stanza of type "subscribed" from the XMPP
>    user to the SIP user; if a subscription already exists, the XMPP

The XMPP server does not communicate (directly) with the SIP user.  It 
has to go through one or both gateways.  (From the architectural 
diagram, I assume the sequence is through both.)  This spec needs to be 
very careful to identify what entity is talking with what entity 
directly and who is mediating, when it isn't direct.

> 3.3.2.  Refreshing a Presence Subscription
>
>    For as long as a SIP user is online and interested in receiving
>    presence notifications from the XMPP users, the user's SIP user agent
>    is responsible for periodically refreshing the subscription by
>    sending an updated SUBSCRIBE request with an appropriate value for

sending it to which actor directly?

>    the Expires header.  In response, the SIMPLE-XMPP gateway MUST send a
>
>
>
> Saint-Andre, et al.      Expires April 21, 2014                 [Page 9]
> 
> Internet-Draft       SIP-XMPP Interworking: Presence        October 2013
>
>
>    SIP NOTIFY to the user agent (per [RFC6665]; if the gateway has
>    meaningful information about the availability state of the XMPP user

This prompts the thought that early in the document, there should 
probably be some discussion about what state information needs to be 
maintained in the gateways.

>    then the NOTIFY MUST communicate that information (e.g., by including
>    a PIDF body [RFC3863] with the relevant data), whereas if the gateway
>    does not have meaningful information about the availability state of
>    the XMPP user then the NOTIFY MUST be empty as allowed by [RFC6665].
>
>    Once the SIP user goes offline at the end of a presence session, it

"goes offline" seems odd phrasing here; I'm not entirely sure what it 
means.  isn't the simple point that the SIP user terminates the presence 
session (for whatever reason)?  If the point is that the SIP user 
literally disappears from the session -- again, there are lots of 
possible reasons, where 'going offline' is only one -- some language 
like that might work better.

> 4.1.  Overview

In general, this overview (4.1) section seems odd to have appear so late 
in the document.  Everything in it feels like stuff that should be in 
Section 1, not Section 4.

>    Both XMPP and presence-aware SIP systems enable entities (often but
>    not necessarily human users) to send presence notifications to other
>    entities.  At a minimum, the term "presence" refers to information
>    about an entity's availability for communication on a network (on/
>    off), often supplemented by information that further specifies the
>    entity's communications context (e.g., "do not disturb").  Some
>    systems and protocols extend this notion even further and refer to
>    any relatively ephemeral information about an entity as a kind of
>    presence; categories of such "extended presence" include geographical

The above text seems a bit confusing.  First it distinguishes between 
presence and status, and then describes something which is both as 
'extended status.'

Here's my guess about what is needed:

1. Very narrow and precise use of the term presence; I think that means 
it only mean "connected to a presence service", or somesuch.

2. Consistent distinction of presence-related attributes, like do not 
disturb.  What's missing here is a simple term for it.

3. Clarity that "ephemeral information about an entity" is probably a 
form of #2, rather than #1.  That is, I think it's a presence attribute, 
rather than "a presence".

And if I've gotten this entirely confused, then that means the text 
needs a different kind of fixing...

>    location (e.g., GPS coordinates), user mood (e.g., grumpy), user
>    activity (e.g., walking), and ambient environment (e.g., noisy).  In
>    this document, we focus on the "least common denominator" of network
>    availability only, although future documents might address broader
>    notions of presence, including extended presence.
>
>
>
>
> Saint-Andre, et al.      Expires April 21, 2014                [Page 12]
> 
> Internet-Draft       SIP-XMPP Interworking: Presence        October 2013
>
>
>    [RFC6121] defines how XMPP presence stanzas can indicate availability
>    (via absence of a 'type' attribute) or lack of availability (via a
>    'type' attribute with a value of "unavailable").  SIP presence using
>    a SIP event package for presence is specified in [RFC3856].
>
>    As described in [RFC6121], presence information about an entity is

    information -> XMPP information

>    communicated by means of an XML <presence/> stanza sent over an XML
>    stream.  In this document we will assume that such a presence stanza
>    is sent from an XMPP client to an XMPP server over an XML stream
>    negotiated between the client and the server, and that the client is
>    controlled by a human user (again, this is a simplifying assumption
>    introduced for explanatory purposes only).  In general, XMPP presence
>    is sent by the user to the user's server and then broadcasted to all
>    entities who are subscribed to the user's presence information.

http://www.dailywritingtips.com/broadcast-vs-broadcasted-as-past-form/

In spite of having some formal linguistic legitimacy, I suggest using 
'broadcast'.

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

> 4.2.  XMPP to SIP
>
>    When Juliet interacts with her XMPP client to modify her presence
>    information (or when her client automatically updates her presence
>    information, e.g. via an "auto-away" feature), her client generates
>    an XMPP <presence/> stanza.  The syntax of the <presence/> stanza,
>    including required and optional elements and attributes, is defined
>    in [RFC6121].  The following is an example of such a stanza:
>
>    Example 17: XMPP user sends presence notification:
>
>    |  <presence from=[email-masked]/balcony'/>
>
>    Upon receiving such a stanza, the XMPP server to which Juliet has
>    connected broadcasts it to all subscribers who are authorized to
>    receive presence notifications from Juliet (this is similar to the
>    SIP NOTIFY method).  For each subscriber, broadcasting the presence
>    notification involves either delivering it to a local recipient (if
>    the hostname in the subscriber's address matches one of the hostnames
>    serviced by the XMPP server) or attempting to route it to the foreign
>    domain that services the hostname in the subscriber's address.  Thus
>
>
>
> Saint-Andre, et al.      Expires April 21, 2014                [Page 13]
> 
> Internet-Draft       SIP-XMPP Interworking: Presence        October 2013
>
>
>    the XMPP server needs to determine the identity of the domainpart in
>    the 'to' address, which it does by following the procedures discussed
>    in [I-D.ietf-stox-core].  Here we assume that the XMPP server has
>    determined the domain is serviced by a SIMPLE server, that it

again, the idea that a pure xmpp server can 'know' about a simple 
destination doesn't make sense to me.  (And by that way, is it simple or 
is it sip...? Note that the term 'simple' hasn't been getting used in 
this document.)

at a minimum, this is a good place to repeat the pointer to text that 
explains how gateways are operational fit into two native networks, 
where their nature is transparent -- that is, with the native entities 
thinking they are merely talking to other native entities.

>    contains or has available to it an XMPP-SIMPLE gateway or connection
>    manager (which enables it to speak natively to SIMPLE servers), and
>    that it hands off the presence stanza to the XMPP-SIMPLE gateway.
>
>    The XMPP-SIMPLE gateway is then responsible for translating the XMPP
>    presence stanza into a SIP NOTIFY request and included PIDF document
>    from the XMPP user to the SIP user.
>
>    Example 18: XMPP user sends presence notification (SIP
>    transformation):
>
>    |  NOTIFY sip:192.0.2.2 SIP/2.0
>    |  Via: SIP/2.0/TCP x2s.example.com;branch=z9hG4bKna998sk
>    |  From: <sip:[email-masked]>;tag=gh19
>    |  To: <sip:[email-masked]>;tag=yt66
>    |  Contact: <sip:[email-masked]>;gr=balcony
>    |  Call-ID: 2B44E147-3B53-45E4-9D48-C051F3216D14
>    |  Event: presence
>    |  Subscription-State: active;expires=599
>    |  Max-Forwards: 70
>    |  CSeq: 157 NOTIFY
>    |  Contact: <sip:x2s.example.com;transport=tcp>
>    |  Content-Type: application/pidf+xml
>    |  Content-Length: 192
>    |
>    |  <?xml version='1.0' encoding='UTF-8'?>
>    |  <presence xmlns='urn:ietf:params:xml:ns:pidf'
>    |            entity='pres:[email-masked]'>
>    |    <tuple id='ID-balcony'>
>    |      <status>
>    |        <basic>open</basic>
>    |        <show xmlns='jabber:client'>away</show>
>    |      </status>
>    |    </tuple>
>    |  </presence>
>
>    The mapping of XMPP syntax elements to SIP syntax elements SHOULD be
>    as shown in the following table.  (Mappings for elements not
>    mentioned are undefined.)
>
>
>
>
>
>
>
>
> Saint-Andre, et al.      Expires April 21, 2014                [Page 14]
> 
> Internet-Draft       SIP-XMPP Interworking: Presence        October 2013
>
>
>    Table 1: Presence syntax mapping from XMPP to SIP
>
>       +-----------------------------+---------------------------+
>       |  XMPP Element or Attribute  |  SIP Header or PIDF Data  |
>       +-----------------------------+---------------------------+
>       |  <presence/> stanza         |  "Event: presence" (1)    |
>       |  XMPP resource identifer    |  tuple 'id' attribute (2) |
>       |  from                       |  From                     |
>       |  id                         |  CSeq (3)                 |
>       |  to                         |  To                       |
>       |  type                       |  basic status (4) (5)     |
>       |  xml:lang                   |  Content-Language         |
>       |  <priority/>                |  priority for tuple (6)   |
>       |  <show/>                    |  no mapping (7)           |
>       |  <status/>                  |  <note/>                  |
>       +-----------------------------+---------------------------+

The format of this makes the table reads as two (unsynchronized) 
columns, rather than a series of rows.

I suggest different formatting, such as (in spite of it's being longer:

         +-----------------------------+---------------------------+
         |  XMPP Element or Attribute  |  SIP Header or PIDF Data  |
         +-----------------------------+---------------------------+
         |  <presence/  stanza            "Event: presence" (1)    |
         +-----------------------------+---------------------------+
         |  XMPP resource identifer       tuple 'id' attribute (2) |
         +-----------------------------+---------------------------+
         |  from                          From                     |
         +-----------------------------+---------------------------+
         |  id                            CSeq (3)                 |
         +-----------------------------+---------------------------+
         |  to                            To                       |
         +-----------------------------+---------------------------+
         |  type                          basic status (4) (5)     |
         +-----------------------------+---------------------------+
         |  xml:lang                      Content-Language         |
         +-----------------------------+---------------------------+
         |  <priority/>                   priority for tuple (6)   |
         +-----------------------------+---------------------------+
         |  <show/>                       no mapping (7)           |
         +-----------------------------+---------------------------+
         |  <status/>                     <note/>                  |
         +-----------------------------+---------------------------+

>    Note the following regarding these mappings:
>
>    1.  Only a presence stanza that lacks a 'type' attribute or whose

    presence -> XMPP presence

>        '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?

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

So, SIP is more macho than XMPP???

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 13 Dec 2013 15:47:05 -0700

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:
> 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.
> 
> explain why the current work is expected to be more successful. 

Not "expected", but "is". :-) AFAIK there are no implementations of the
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,

Do you think that explaining why would improve the document? IMHO this
verges into developer psychology (I've got this SIP thing here and this
XMPP thing there, let me see how I can make them work as easily as
possible without venturing off into abstract semantic stuff).

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

> familiar with those documents. 

I do think it's required.

> If that's what this document requires,
>    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
> 

I'll review the document again with these comments in mind. Your
suggestion of sequence diagrams is a good one.

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

> This begs the obvious question:  Why?  What was wrong with the previous

No one implemented it. The running code all takes the direct gatewaying
approach.

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

> understanding the current draft, and where to get that knowledge.

Agreed.

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

> list format.  It really does help for quick comprehension.

Will fix.

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

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

> Move definition of contact up to first occurrence, above.

Yes.

> of the document that is relevant to this context.

Agreed.

> follows, I fear that indeed, this document requires deep familiarity

I definitely think that's so. All of the STOX WG documents build upon
the framework described in draft-ietf-stox-core.

>      Example 2: Translation of XMPP user's subscription request into SIP

Yes, that's better.

> Later text (section 4.1) equates the label pres: with sip: and sips:.

In practice, we don't see 'pres' URIs in the wild.

> separate display of it's being translated into XMPP.

That is Example 5.

> Where is the xmpp translation of this?

That is Example 6.

> have to guess; this is a spec.)

The gateways sends it to the SIP user agent. Will clarify.

> the type used in rfc5263.

Yes, some "swim lanes" are in order here and throughout.

> the life of an implementer /much/ easier.

Agreed.

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

> directly and who is mediating, when it isn't direct.

Yes, we need more clarity about "service", "server", and "gateway".

> sending it to which actor directly?

To the XMPP user (although the SIP user wouldn't know that the user is
on the XMPP side of the wormhole, since the gateway masks that fact).

> maintained in the gateways.

Good point.

> like that might work better.

We can just say "ends its presence session".

> Section 1, not Section 4.

It's an overview of how notifications work, but you might be right that
some of it belongs earlier in the document. I'll review the section with
your feedback in mind.

> it only mean "connected to a presence service", or somesuch.

It's best not to conflate presence with a physical or virtual
connection, because one can be present even if disconnected (usually for
a short period of time).

Citing RFC 2778 might be sensible here.

> disturb.  What's missing here is a simple term for it.

In XMPP we refer to "presence" (online/offline) and "availability
states" when an entity is online (away, do not disturb, etc.). We also
have human-readable descriptions for such states (e.g., "in a meeting").

> rather than "a presence".

Such ephemeral information might include things like the user's mood,
what tune is playing on their music player, etc.

>    information -> XMPP information

Right.

> In spite of having some formal linguistic legitimacy, I suggest using

Yep.

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

> thinking they are merely talking to other native entities.

Yes. See above.

> I suggest different formatting, such as (in spite of it's being longer:

Agreed.

>    presence -> XMPP presence

Stanzas are an XMPP artifact. But yes.

> gatewaying semantics.  How can interoperability tolerate it's being

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.

> Romeo is doing SIP?  And Juliet does XMPP?

You noticed, eh? "Juliet does Jabber" makes it easy to remember, at
least for me.

> 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
character and a female character for diversity purposes, with message
text that is in the public domain and widely translated into something
other than English for internationalization examples.

Thanks for the thorough review. I'll work to address your feedback and
submit a revised I-D.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Dave Crocker <[email-masked]>
Date: Tue, 17 Dec 2013 07:39:20 -0800

Only responded where it seems needed or useful...

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

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

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

> See above. Perhaps not expert level, but significant familiarity with

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.

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

>> separate display of it's being translated into XMPP.

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

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

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

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

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

> You noticed, eh? "Juliet does Jabber" makes it easy to remember, at

So why isn't the other side Steve or Sid or...

Nevermind...

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