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

Spencer Dawkins at IETF <> Thu, 05 March 2015 17:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5364C1A1B62; Thu, 5 Mar 2015 09:28:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Lwijh7FDJmpQ; Thu, 5 Mar 2015 09:28:48 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1E6881A07BE; Thu, 5 Mar 2015 09:28:42 -0800 (PST)
Received: by lamq1 with SMTP id q1so29880726lam.9; Thu, 05 Mar 2015 09:28:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ooRbP2ZahFRMwpvlHu8IRZhE2W//n0OyXifNNKJKY9I=; b=MLI/pLgGwQ7J7kGZMAlNIyPmQXnu67muKXNSFqoA2pjp7lb0rrBY9b825ylVjADKeZ 2n29NX9/qRK09ORc6jyt1G+ESisMhBS7wS1NfUHph/tgniWtCr4dsb8Kplvp3lPFhGby b4jjbiszRP0ssIdjJK9WYpUNRsRiLa0iiwS3ZfaPkNp88tCtbsKJXkgWSY/Yrx6EZ3j+ DpeH12mCDrcPFWktzwaPa/IpyMA0LjyLgmzGXWfrkE+LnWgj1eoCUEMQoDnq13n88o5E b172N6tudzaCjeLi6Rs2NEpcfy0AlLAZTQ5hNnHA81SsUCKpWmIHum9XrtTvW1I4fLXM CClg==
MIME-Version: 1.0
X-Received: by with SMTP id ek9mr9232669lbb.68.1425576520559; Thu, 05 Mar 2015 09:28:40 -0800 (PST)
Received: by with HTTP; Thu, 5 Mar 2015 09:28:40 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Thu, 5 Mar 2015 11:28:40 -0600
Message-ID: <>
From: Spencer Dawkins at IETF <>
To: "Peter Saint-Andre - &yet" <>
Content-Type: multipart/alternative; boundary=001a11345c8c1bb0e205108de639
Archived-At: <>
Cc:,,, The IESG <>,
Subject: Re: [Stox] Spencer Dawkins' No Objection on draft-ietf-stox-im-12: (with COMMENT)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Mar 2015 17:28:50 -0000

Hi, Peter,

On Thu, Mar 5, 2015 at 10:27 AM, Peter Saint-Andre - &yet <>

> 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
>> for more information about IESG DISCUSS and COMMENT positions.
>> The document, along with other ballot positions, can be found here:
>> ----------------------------------------------------------------------
>> ----------------------------------------------------------------------
>> 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 <
>> 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.