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

[Dave Crocker <[e-mail]>]

Only responded where it seems needed or useful...



On 12/13/2013 2:47 PM, Peter Saint-Andre wrote:

>>     1.  When citing the earlier efforts, there should be something to
>> explain why the current work is expected to be more successful.
>
> Not "expected", but "is". :-) AFAIK there are no implementations of the

I'd missed that this is based on deployed work.  That is a point that 
always makes writing text justifying/motivating the document quite easy: 
  just say that.


> approach taken by RFC 3922 and draft-ietf-simple-cpim-mapping (i.e.,
> mapping to the abstract semantics of RFC 3860), whereas there are
> multiple implementations of the approach described here (i.e., direct
> mapping between SIP and XMPP).
>
>> That is,
>> what makes the current approach notably tractable for implementation and
>> deployment?
>
> Do you think that explaining why would improve the document? IMHO this

I'm a fan of context and systems views, because I think it orients the 
reader usefully, so the simple answer is yes.

Whenever there is a lengthy history with alternative efforts, readers 
can benefit from some context that distinguishes the current work.  Not 
in qualitative terms like better or worse, but in technical and 
operational terms.

Hence I think language like what's already in the document, that 
distinguishes the 'architectural' difference from earlier work, but also 
one that says that the current work is based on deployed industry choice.


> verges into developer psychology (I've got this SIP thing here and this


>>     5.  When showing protocol examples, usually only one side of the
>> sequence is shown.  For gatewaying that does interesting transforms,
>> such as this one, an example should show both the before and after
>> versions.  That is, the 'native' protocol unit that was created and then
>> the one that results from the translation.
>
> I thought we'd already done that. For instance, Example 2 is the SIP
> transformation of the XMPP stanza shown in Example 1.

Either the document didn't do it as diligently as I'm suggesting, or I 
didn't understand this aspect of the document, which might be remedied 
by better labeling.

For any example that is done in a gateway and is a translation between 
sip presence and xmpp presence, something simple and rigorous, such as 
"before" and "after" labels to source and transformed versions, ought to 
remedy this.




>> This probably raises a larger issue:  How much expertise is expected of
>> someone who is implementing this or otherwise reading for deep
>> comprehension?  In the extreme, they will need to have serious expertise
>> on both protocol sets.  The other extreme would be a cookbook inside
>> this document, with no outside knowledge required.  The document needs
>> to specify the nature and extent of the expertise required.  (In fact,
>> the document seems pretty clean, in terms of explaining things, so I
>> suspect that 'fair' knowledge of one suite will suffice.  But the author
>> and wg beliefs about the requirement should be made explicit.)
>
> See above. Perhaps not expert level, but significant familiarity with
> one "side" or the other.

Just to emphasize, whatever the knowledge-level of reader that's 
required, the document should make that explicit.

I'm always a fan of making documents more accessible to wider 
readership, but it's not practical to make all documents fully 
accessible, especially within a suite of docs that build on each other.


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

Hmmm.  While 'statistics' of use is a relatively fragile basis for 
putting things into a spec -- since a doc can last for decades and 
statistics can change -- it might be worth mentioning as the basis for 
the choice in the doc.  I suppose that's in the realm of giving the 
reader a bit of operational insight.  But definitely not an important point.



>>>     Example 3: SIP accepts subscription request:
>>>
>>>     |  SIP/2.0 200 OK
>>>     |  Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKna998sk
>>>     |  From: <sip:[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.

Oh. It's worth making that explicit.  (My tendency to get confused 
reading specs is a useful canary in the tunnel, for what needs 
clarifying for other readers, IMO...)



>>>     Example 10: SIP user subscribes to XMPP contact:
>>>
>>>     |  SUBSCRIBE sip:[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

I think this matches the usual model:  an unchanged server does routing 
as if all participants were part of its 'native' protocol service.  A 
gateway translates and tries to hide any differences between two services.

The current doc language seems confusing on this point, when it talks 
about a (native) server choosing a server that is part of the other service.

This is a sufficiently basic point to probably warrant going into -core, 
rather than here.  But the language here probably therefore ought to 
just be in terms of originators and recipients (or whatever generic 
terminology works for presence) with an initial, simple note that 
knowledge of the need for translation only resides in the gateway(s).

But I'm not sure I mentioned another point that confused me from -core: 
  It shows the two types of gateways as talking to each other, but I 
suspect that's not reality.  FOr example, when doing SIP-XMPP, I suspect 
the actual flow is:

    SIP User
    SIP Server
    SIP-XMPP Server
    XMPP Server
    XMPP User

whereas the implication from the -core diagram and some of the language 
in the spec(s) is:

    SIP User
    SIP Server
    SIP-XMPP Server
    XMPP-SIP Server
    XMPP Server
    XMPP Use

If it really is the later sequence, I don't understand why.



> the remote XMPP domain. To some extent it's a matter of implementation
> where exactly the code lives to complete these functions, which is why
> draft-ietf-stox-core talks about a "SIP service" consisting of both a
> SIP "server" and a "gateway". In XMPP this translation function is often
> handled by what we call a "connection manager", but that depends a bit
> on the internal architecture of the overall "service".

This point highlights the essential difference between a "networking 
architecture" and an "implementation architecture".

Mapping from the first to the second often permits very wide variations. 
  The former concerns distinct functionality that /can/ be distributed, 
where the latter makes specific choices for what /is/ distributed.




>>>     As described in [RFC3856], presence information about an entity is
>>>     communicated by means of a SIP NOTIFY event sent from a SIP user
>>>     agent to an intended recipient who is most generally referenced by an
>>>     Presence URI of the form <pres:user@domain> but who might be
>>>     referenced by a SIP or SIPS URI of the form <sip:user@domain> or
>>>     <sips:user@domain>.  Here again we introduce the simplifying
>>>     assumption that the user agent is controlled by a human user.
>>
>> I guess I'm not understanding how the nature of what is controlling the
>> agent affects anything in this document.  Might be worth explaining that.
>
> A "presentity" doesn't have to be a human -- it could be a bot, a
> device, or some other automated entity. People related more to human users.

Sure, but when reading the doc, it felt as if the reference to this 
issue was relevant to functionality.  I'd expect the issue to be raised 
once in an Intro and then avoided later by use of a neutral term like 
user or presentity or whatever.



>>>     Note the following regarding these mappings:
>>>
>>>     1.  Only a presence stanza that lacks a 'type' attribute or whose
>>
>>     presence -> XMPP presence
>
> Stanzas are an XMPP artifact. But yes.

Choosing the level of semantic redundancy in the language is always a 
balancing act.  In a gatewaying document that will be reader by folks 
likely to be expert in only one half of the necessary technologies, I'd 
be inclined towards more redundancy, to reduce likelihood of 
misunderstanding...



>>>         'type' attribute has a value of "unavailable" SHOULD be mapped by
>>>         an XMPP-SIMPLE gateway to a SIP NOTIFY request, since those are
>>>         the only presence stanzas that represent notifications.
>>>     2.  The PIDF schema defines the tuple 'id' attribute as having a
>>>         datatype of "xs:ID"; because this datatype is more restrictive
>>>         than the "xs:string" datatype for XMPP resourceparts (in
>>>         particular, a number is not allowed as the first character of an
>>>         ID), it is RECOMMENDED to prepend the resourcepart with "ID-" or
>>>         some other alphabetic string when mapping from XMPP to SIP.
>>>     3.  This mapping is OPTIONAL.
>>
>> What does that mean?  This sort of mapping is usually the essence of
>> gatewaying semantics.  How can interoperability tolerate it's being
>> optional?
>
> In XMPP, the 'id' attribute is not usually included in presence stanzas,
> and nothing is lost if it's ignored. But I'll give it a bit more thought.
>
>>> 4.3.  SIP to XMPP
>>>
>>>     When Romeo changes his presence, his SIP user agent generates a SIP
>>
>> Romeo is doing SIP?  And Juliet does XMPP?
>
> You noticed, eh? "Juliet does Jabber" makes it easy to remember, at
> least for me.

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

Nevermind...



>> So, SIP is more macho than XMPP???
>
> Have you configured a SIP client lately? ;-)
>
> But seriously, the Romeo and Juliet scenarios enable me to use a male

The word seriously is entirely out of scope for this segment.  Or at 
least, it certainly was when I started it...

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net