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

Done!

On 01/21/2014 08:57 AM, Gonzalo Camarillo wrote:
> 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:romeo@example.net 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: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.
>>>
>>> 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: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??
>>>
>>> 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/
>>
> 
> _______________________________________________
> stox mailing list
> stox@ietf.org
> https://www.ietf.org/mailman/listinfo/stox
> 