Re: [Stox] Comments on stox-chat-09

Ben Campbell <ben@nostrum.com> Thu, 12 February 2015 05:01 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA6031A8FD5 for <stox@ietfa.amsl.com>; Wed, 11 Feb 2015 21:01:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBM4jthHNxSj for <stox@ietfa.amsl.com>; Wed, 11 Feb 2015 21:01:11 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C788F1A8AD9 for <stox@ietf.org>; Wed, 11 Feb 2015 21:01:11 -0800 (PST)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id t1C515lO058004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Feb 2015 23:01:06 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
Content-Type: multipart/signed; boundary="Apple-Mail=_2372FFEC-BD24-40FF-ACD1-BD0CB6E12AC7"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
X-Pgp-Agent: GPGMail 2.5b5
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <54DC1F86.6020709@andyet.net>
Date: Wed, 11 Feb 2015 23:01:05 -0600
X-Mao-Original-Outgoing-Id: 445410065.22193-0b6895e9ebb086e11720bea1c105908a
Message-Id: <2EF02818-EB21-494C-95C9-1A1961BA912A@nostrum.com>
References: <10EF4B6B-A78E-4714-8E0F-84B985456266@nostrum.com> <54DC1F86.6020709@andyet.net>
To: Peter Saint-Andre - &yet <peter@andyet.net>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/stox/EnEkLrmBl3wecOoqSESRSeVMLRM>
Cc: stox@ietf.org, Alissa Cooper <alissa@cooperw.in>
Subject: Re: [Stox] Comments on stox-chat-09
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Feb 2015 05:01:13 -0000

> On Feb 11, 2015, at 9:35 PM, Peter Saint-Andre - &yet <peter@andyet.net> wrote:
> 
> On 2/9/15 3:59 PM, Ben Campbell wrote:
>> (Resending to include STOX list) (No hats yet)
>> 
>> Hi Peter and Alissa,
>> 
>> I've looked over draft-ietf-stox-chat-09. It looks mostly good, but
>> there are still a few issues.
>> 
>> Thanks!
>> 
>> /Ben
>> 
>> ----------------------------
>> 
>> MSRP Failure-Report headers:
>> 
>> The examples assume the MSRP Failure-Report header field is set to
>> no. It's missing from the first SEND, but explicitly set to no in the
>> rest. The responses to SEND requests are left off throughout. This is
>> allowed, but non-default behavior for MSRP. If the intent is to set
>> Failure-Report: no, it would be good to say a few words about it. If
>> the intent is to leave that to the implementation, then I would
>> expect the examples to follow the defaults.
> 
> As I see it:
> 
> Because the XMPP message receipts specification (XEP-0184) does not support failure reports, there is no mapping for the MSRP Failure-Report header field and gateways SHOULD set that header field to "no".
> 

That's reasonable. A few words to that effect might help keep others from tripping over it.

[...]

>> Session Termination
>> 
>> I would like to see a little more prominent discussion about when the
>> XMPP side might terminate a session. It's mentioned in the
>> "Composing" section, but that seems to bury an important concept. I
>> note both primary examples show the SIP side terminating the
>> session--it would be nice to see one of those examples let the XMPP
>> side do it.  (Is the "gone" composing state the only way this would
>> happen?)
> 
> There is no concept of an explicit messaging session in RFC 6121: the conversation just trails off. The "gone" state is the only way to indicate that the session is over, but that's not defined in RFC 6121.

Got it. Then my only real comment here is it might be nice (but completely optional) to say something about that in the main flow examples, instead of bury it in the "composing" state section.

> 
>> SIP CSeq:
>> 
>> CSeq is missing from most SIP requests, except oddly for BYE
>> requests.
> 
> Are you saying that CSeq is typically not included in SIP requests (even in dialogs) per the specs, or that we have mistakenly left them off here? I think the latter, but I want to make sure.
> 

The latter. "most SIP requests" should have been "most SIP requests in this draft".

[...]