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

[Peter Saint-Andre <[e-mail]>]

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

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

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

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

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

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

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

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

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

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

See above. Perhaps not expert level, but significant familiarity with
one "side" or the other.

>> 3.2.  XMPP to SIP
>>
>> 3.2.1.  Establishing a Presence Subscription
>>
>>    An XMPP user (e.g., [e-mail]) initiates a subscription by
>>    sending a subscription request to another entity (e.g.,
>>    [e-mail]), and the other entity (conventionally called a
> 
> Move definition of contact up to first occurrence, above.

Yes.

>>    "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='[e-mail]'
>>    |            to='[e-mail]'
>>    |            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.

Agreed.

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

I definitely think that's so. All of the STOX WG documents build upon
the framework described in draft-ietf-stox-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

Yes, that's better.

>>    |  SUBSCRIBE sip:[e-mail] 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.

>>    |  Via: SIP/2.0/TCP x2s.example.com;branch=z9hG4bKna998sk
>>    |  From: <sip:[e-mail]>;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:[e-mail]>;tag=ffd2
>>    |  To: <sip:[e-mail]>;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.

>> 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:[e-mail]>;tag=yt66
>>    |  To: <sip:[e-mail]>;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:[e-mail]'>
>>    |    <tuple id='ID-orchard'>
>>    |      <status>
>>    |        <basic>open</basic>
>>    |        <show xmlns='jabber:client'>away</show>
>>    |      </status>
>>    |    </tuple>
>>    |  </presence>
> 
> Where is the xmpp translation of this?

That is Example 6.

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

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

>>    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='[e-mail]'
>>    |            to='[e-mail]'
>>    |            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='[e-mail]/orchard'
>>    |            to='[e-mail]'/>
> 
> 
> This sequence feels like it should have a protocol sequence diagram, of
> the type used in rfc5263.

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

>> 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='[e-mail]'
>>    |            to='[e-mail]'
>>    |            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:[e-mail] SIP/2.0
>>    |  Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKna998sk
>>    |  From: <sip:[e-mail]>;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='[e-mail]'
>>    |            to='[e-mail]'
>>    |            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.

Agreed.

>> 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:[e-mail] SIP/2.0
>>    |  Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKna998sk
>>    |  From: <sip:[e-mail]>;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
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".

>>    Example 11: SIP user subscribes to XMPP contact (XMPP
>>    transformation):
>>
>>    |  <presence from='[e-mail]'
>>    |            to='[e-mail]'
>>    |            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.

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

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

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

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

Good point.

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

We can just say "ends its presence session".

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

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.

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

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.

> 2. Consistent distinction of presence-related attributes, like do not
> 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").

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

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

> 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

Right.

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

Yep.

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

>> 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='[e-mail]/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.

Yes. See above.

>>    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:[e-mail]>;tag=gh19
>>    |  To: <sip:[e-mail]>;tag=yt66
>>    |  Contact: <sip:[e-mail]>;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:[e-mail]'>
>>    |    <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/>                  |
>         +-----------------------------+---------------------------+

Agreed.

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

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