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., juliet@example.com) initiates a subscription by
>    sending a subscription request to another entity (e.g.,
>    romeo@example.net), 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='juliet@example.com'
>    |            to='romeo@example.net'
>    |            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:romeo@example.net 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:juliet@example.com>;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:romeo@example.net>;tag=ffd2
>    |  To: <sip:juliet@example.com>;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:romeo@example.net>;tag=yt66
>    |  To: <sip:juliet@example.com>;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:romeo@example.net'>
>    |    <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='romeo@example.net'
>    |            to='juliet@example.com'
>    |            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='romeo@example.net/orchard'
>    |            to='juliet@example.com'/>


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='juliet@example.com'
>    |            to='romeo@example.net'
>    |            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:romeo@example.net SIP/2.0
>    |  Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKna998sk
>    |  From: <sip:juliet@example.com>;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='romeo@example.net'
>    |            to='juliet@example.com'
>    |            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:juliet@example.com SIP/2.0
>    |  Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKna998sk
>    |  From: <sip:romeo@example.net>;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='romeo@example.net'
>    |            to='juliet@example.com'
>    |            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='juliet@example.com/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:juliet@example.com>;tag=gh19
>    |  To: <sip:romeo@example.net>;tag=yt66
>    |  Contact: <sip:juliet@example.com>;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:juliet@example.com'>
>    |    <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