Re: [Stox] Spencer Dawkins' No Objection on draft-ietf-stox-im-12: (with COMMENT)

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Peter,

On Thu, Mar 5, 2015 at 10:27 AM, Peter Saint-Andre - &yet <[e-mail]>
wrote:

> Hi Spencer, thanks for the review. Comments inline.
>
> On 3/4/15 10:11 PM, Spencer Dawkins wrote:
>
>> Spencer Dawkins has entered the following ballot position for
>> draft-ietf-stox-im-12: No Objection
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> http://datatracker.ietf.org/doc/draft-ietf-stox-im/
>>
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> I'm glad to see these specifications moving forward. Thanks for that.
>>
>> I have a couple of you-need-smarter-ADs questions. As prologue, please
>> remember I have a decent understanding of SIP, an indecent understanding
>> of SIMPLE, and mostly, I just stare uncomprehendingly when I see raw
>> XMPP.
>>
>> It did not jump out at me when reading this specification, whether there
>> is any assurance to a sender on one side of the gateway that a message
>> was delivered successfully to a receiver on the other side of the
>> gateway.
>>
>
> Assurance is a slippery thing. :-)
>
> In XMPP we do have a way to communicate delivery receipts end-to-end <
> http://xmpp.org/extensions/xep-0184.html> but that's an extension to the
> core specs. Given that MSRP has a similar mechanism for session mode
> messaging, we talk about that in draft-ietf-stox-chat instead of
> draft-ietf-stox-im.


I think I understood that. I was just thinking it might be good to say
something like "IMs don't return an indication of success or failure, and
if you need that, you want to use chat instead".

Is that even true? :-)


> If there's not, that might be worth pointing out a bit earlier
>> than a Note: halfway through page 5.
>>
>> Is there a possible mismatch between what a sender thinks is happening,
>> TLS-wise, on one side of the gateway, and what a receiver actually
>> receives, TLS-wise, on the other side? I'm not smart enough to ask the
>> right question, but if an XMPP sender knows she's sending over TLS, but
>> the XMPP-to-SIP gateway maps that into a non-TLS SIP transaction on the
>> other side, is the kind of scenario I'm thinking of. If so, perhaps it's
>> worth pointing that out someplace (the Security Considerations section
>> would be fine).
>>
>
> RFC 7247 says:
>
>    As specified in Section 26.4.4 of [RFC3261] and updated by [RFC5630],
>    a To header or a Request-URI containing a Session Initiation Protocol
>    Secure (SIPS) URI is used to indicate that all hops in a
>    communication path need to be protected using TLS.  Because XMPP
>    lacks a way to signal that all hops need to be protected, if the To
>    header or Request-URI of a SIP message is a SIPS URI then the SIP-to-
>    XMPP gateway MUST NOT translate the SIP message into an XMPP stanza
>    and MUST NOT route it to the destination XMPP server (there might be
>    exceptions to such a policy, such as explicit agreement among two
>    operators to enforce per-hop security, but currently they are quite
>    rare).
>
> Do you feel that we need to say more here in the IM context?
>

I think that's fine.

Spencer