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

Peter Saint-Andre - &yet <peter@andyet.net> Thu, 12 February 2015 22:02 UTC

Return-Path: <peter@andyet.net>
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 98A931A038C for <stox@ietfa.amsl.com>; Thu, 12 Feb 2015 14:02:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZAvjr4BYgw7 for <stox@ietfa.amsl.com>; Thu, 12 Feb 2015 14:02:39 -0800 (PST)
Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6DFB1A00EA for <stox@ietf.org>; Thu, 12 Feb 2015 14:02:38 -0800 (PST)
Received: by iecar1 with SMTP id ar1so15459561iec.0 for <stox@ietf.org>; Thu, 12 Feb 2015 14:02:38 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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 10.43.100.67 with SMTP id cv3mr11076631icc.92.1423778558247; Thu, 12 Feb 2015 14:02:38 -0800 (PST)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id j6sm2006505igv.4.2015.02.12.14.02.37 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Feb 2015 14:02:37 -0800 (PST)
Message-ID: <54DD22FC.9000907@andyet.net>
Date: Thu, 12 Feb 2015 15:02:36 -0700
From: Peter Saint-Andre - &yet <peter@andyet.net>
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 <ben@nostrum.com>
References: <10EF4B6B-A78E-4714-8E0F-84B985456266@nostrum.com> <54DC1F86.6020709@andyet.net> <2EF02818-EB21-494C-95C9-1A1961BA912A@nostrum.com>
In-Reply-To: <2EF02818-EB21-494C-95C9-1A1961BA912A@nostrum.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/stox/tfYgvoCbYqtwf684ZL2hDm7yS3Y>
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 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
>> <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.

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

-- 
Peter Saint-Andre
https://andyet.com/