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

[Gonzalo Camarillo <[e-mail]>]

Hi Peter,

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

Thanks for the review, Dave.

Cheers,

Gonzalo

On 17/12/2013 4:39 PM, Dave Crocker wrote:
> Only responded where it seems needed or useful...
> 
> 
> 
> On 12/13/2013 2:47 PM, Peter Saint-Andre wrote:
> 
>>>     1.  When citing the earlier efforts, there should be something to
>>> explain why the current work is expected to be more successful.
>>
>> Not "expected", but "is". :-) AFAIK there are no implementations of the
> 
> I'd missed that this is based on deployed work.  That is a point that
> always makes writing text justifying/motivating the document quite easy:
>  just say that.
> 
> 
>> approach taken by RFC 3922 and draft-ietf-simple-cpim-mapping (i.e.,
>> mapping to the abstract semantics of RFC 3860), whereas there are
>> multiple implementations of the approach described here (i.e., direct
>> mapping between SIP and XMPP).
>>
>>> That is,
>>> what makes the current approach notably tractable for implementation and
>>> deployment?
>>
>> Do you think that explaining why would improve the document? IMHO this
> 
> I'm a fan of context and systems views, because I think it orients the
> reader usefully, so the simple answer is yes.
> 
> Whenever there is a lengthy history with alternative efforts, readers
> can benefit from some context that distinguishes the current work.  Not
> in qualitative terms like better or worse, but in technical and
> operational terms.
> 
> Hence I think language like what's already in the document, that
> distinguishes the 'architectural' difference from earlier work, but also
> one that says that the current work is based on deployed industry choice.
> 
> 
>> verges into developer psychology (I've got this SIP thing here and this
> 
> 
>>>     5.  When showing protocol examples, usually only one side of the
>>> sequence is shown.  For gatewaying that does interesting transforms,
>>> such as this one, an example should show both the before and after
>>> versions.  That is, the 'native' protocol unit that was created and then
>>> the one that results from the translation.
>>
>> I thought we'd already done that. For instance, Example 2 is the SIP
>> transformation of the XMPP stanza shown in Example 1.
> 
> Either the document didn't do it as diligently as I'm suggesting, or I
> didn't understand this aspect of the document, which might be remedied
> by better labeling.
> 
> For any example that is done in a gateway and is a translation between
> sip presence and xmpp presence, something simple and rigorous, such as
> "before" and "after" labels to source and transformed versions, ought to
> remedy this.
> 
> 
> 
> 
>>> This probably raises a larger issue:  How much expertise is expected of
>>> someone who is implementing this or otherwise reading for deep
>>> comprehension?  In the extreme, they will need to have serious expertise
>>> on both protocol sets.  The other extreme would be a cookbook inside
>>> this document, with no outside knowledge required.  The document needs
>>> to specify the nature and extent of the expertise required.  (In fact,
>>> the document seems pretty clean, in terms of explaining things, so I
>>> suspect that 'fair' knowledge of one suite will suffice.  But the author
>>> and wg beliefs about the requirement should be made explicit.)
>>
>> See above. Perhaps not expert level, but significant familiarity with
>> one "side" or the other.
> 
> Just to emphasize, whatever the knowledge-level of reader that's
> required, the document should make that explicit.
> 
> I'm always a fan of making documents more accessible to wider
> readership, but it's not practical to make all documents fully
> accessible, especially within a suite of docs that build on each other.
> 
> 
>>>>     |  SUBSCRIBE sip:[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/
>