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

Peter Saint-Andre - &yet <> Thu, 05 March 2015 16:32 UTC

Return-Path: <>
Received: by (Postfix, from userid 65534) id 03B4A1A1A0C; Thu, 5 Mar 2015 08:32:57 -0800 (PST)
Received: from localhost ( []) by (Postfix) with ESMTP id DA3861A19E5 for <>; Thu, 5 Mar 2015 08:32:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BGzL8g_A6vCK for <>; Thu, 5 Mar 2015 08:32:56 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3D6511A0242 for <>; Thu, 5 Mar 2015 08:27:49 -0800 (PST)
Received: by igbhl2 with SMTP id hl2so47261066igb.5 for <>; Thu, 05 Mar 2015 08:27:48 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=gXO+trQpOuv4YB0z/Rj60KyYzDF90wwaGj84ukudUhM=; b=STq6WX19G1yJOdUL5abqrfG/XJAwXVbL4tl8ZfytGlz/ZGAdXdRp3yoGdVsFe5GZKO GzwFDNWbyUmtgAcPwJN70gL+oAz4dG8fpF46Nr18NM/rw18VVj3WWpuSClerWxSlBput Id2tHqMM4XyWbcqNvLDF6Ni9tG9IMjzIhvYTmX5GCYdT/vHybxPWUsViTeSWUZ0VDNyF usQjZO953iFlmSyp9PJsqr2EpYSmqZ2kIfNXLSeGkDU/9wXGLQnGWagYNg/7iLDa2HSB n78vfAXE4vGwe7+1BEnSpjZo6op9LrKEtDIwnXuZLqJGQYB8SIkJFwSj+etetSVoc4Xi uCig==
X-Gm-Message-State: ALoCoQkEpBG9UM5ur97pqC71eXpPCOHmw6iGsZQ8BFS3N8Y6b9SSIbLTmerJnluDik0VBb+PCyj0
X-Received: by with SMTP id d13mr20935505ioe.29.1425572868601; Thu, 05 Mar 2015 08:27:48 -0800 (PST)
Received: from aither.local ( []) by with ESMTPSA id k9sm5292143ige.6.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Mar 2015 08:27:47 -0800 (PST)
Message-ID: <>
Date: Thu, 05 Mar 2015 09:27:47 -0700
From: Peter Saint-Andre - &yet <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Spencer Dawkins <>, The IESG <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
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 16:32:58 -0000

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
> 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 

> 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

Do you feel that we need to say more here in the IM context?


Peter Saint-Andre