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

Peter Saint-Andre - &yet <> Thu, 12 February 2015 22:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 98A931A038C for <>; Thu, 12 Feb 2015 14:02:41 -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=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0ZAvjr4BYgw7 for <>; Thu, 12 Feb 2015 14:02:39 -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 C6DFB1A00EA for <>; Thu, 12 Feb 2015 14:02:38 -0800 (PST)
Received: by iecar1 with SMTP id ar1so15459561iec.0 for <>; Thu, 12 Feb 2015 14:02:38 -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=cBrSaQwJrwuvPBLaMX5rYlb9mm9d0m/ysik/XO0CAJ0=; b=CtEOE6du0yo5ChEfr2/dOlHawYyRxU+P8Odh3ZIbmtVcqkuH+Eam4OBTuxQ/KgM3j8 fqsHJfdGkg0O2Jan49awmjAjT0nlYXclWERBsPqLAtwnTW2ewWkH8ewXM+lhm13Qn4yK dIfasqV/aV6lV8NJndhVCoAibsKvZtZ1NXpw0of2KkQVh3OB5BnMzE0uP3K5scfvc60Z mKJUlxMx/8lHil2UPAt/66YQw90RYOVaeeQyaHHjL1/WYX7hgR2aelpywsj5gZwRnVw5 Z/rw851p5hgvkpirEDq2VmhVrIOt4sAsk1lz7kjBp4TkP1BX7fidrLhG4VcVI8eJQtzo pkWQ==
X-Gm-Message-State: ALoCoQn4tXeemY6I9QWjyFWF0RhEfg2hwrkNl3wZWt9QpoY79aHZnhBqN6FjXeZXhxbeHTgniv2K
X-Received: by with SMTP id cv3mr11076631icc.92.1423778558247; Thu, 12 Feb 2015 14:02:38 -0800 (PST)
Received: from aither.local ( []) by with ESMTPSA id j6sm2006505igv.4.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Feb 2015 14:02:37 -0800 (PST)
Message-ID: <>
Date: Thu, 12 Feb 2015 15:02:36 -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.4.0
MIME-Version: 1.0
To: Ben Campbell <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
Cc:, Alissa Cooper <>
Subject: Re: [Stox] Comments on stox-chat-09
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, 12 Feb 2015 22:02:42 -0000

On 2/11/15 10:01 PM, Ben Campbell wrote:
>> On Feb 11, 2015, at 9:35 PM, Peter Saint-Andre - &yet
>> <> 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.

Here's what I have in Section 7 of my working copy...

    Because the XMPP Message Receipts specification 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".

> [...]
>>> 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.

Perhaps this at the end of Section 4:

    In addition, there is no explicit method defined in [RFC6121] for an
    XMPP user to formally terminate a chat session, so a gateway would
    need to listen for a "gone" chat state notification from the XMPP
    user or institute a timer that considers the XMPP informal chat
    session to be ended after some amount of time has elapsed.

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

OK, we'll add those in. I notice that the presence document has them...


Peter Saint-Andre