Re: [Stox] AD evaluation: draft-ietf-stox-chat-08

Alissa Cooper <alissa@cooperw.in> Mon, 09 February 2015 23:44 UTC

Return-Path: <alissa@cooperw.in>
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 4F5FC1A8A9D for <stox@ietfa.amsl.com>; Mon, 9 Feb 2015 15:44:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 PhiLU2gNRCRm for <stox@ietfa.amsl.com>; Mon, 9 Feb 2015 15:44:05 -0800 (PST)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 164491A8AAA for <stox@ietf.org>; Mon, 9 Feb 2015 15:44:05 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 8375B20E46 for <stox@ietf.org>; Mon, 9 Feb 2015 18:44:04 -0500 (EST)
Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Mon, 09 Feb 2015 18:44:04 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= x-sasl-enc:content-type:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; s= mesmtp; bh=eliGbi5JGtiX58eZkMTg/7iI7HQ=; b=ZsXKOWS3W3SBfgDLENa98 h0jhlJh1L/m+qFri1NVFpmynd/yrp1yCL83KomLpUNfkDvNYBWpRCKoWl1JopEkt s9nS9ICllNt0nvC3l9fz/FSGep2P1YJ51mj7S1RU3EvJ5XQ2EsGS8iuB/Lr2zRiO 8t+jjxZumszyThPOXtNfbo=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:content-type:mime-version :subject:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; s=smtpout; bh=eliGbi5JGtiX58eZkMTg/7i I7HQ=; b=A1+YH3tJOWIMj7Pu8Wsf7HdlrzhJmnpkLXGySQx/p/8HXUXq9KSNtTR caOa6x4+hsuBRkbglnfkiWohIx2QmzutUj3ljlo9GtzmpN1qiynjRFieNykHwKcX kM8ztoRZnaEq1m3vjc5NVFrmQXWe10r+NlQj4qUHRNAyDEa8OedU=
X-Sasl-enc: xTss/2fhls8R9eunOiCr7a49pufWrbomqGHeyHqtHxp9 1423525444
Received: from sjc-alcoop-8817.cisco.com (unknown [128.107.239.235]) by mail.messagingengine.com (Postfix) with ESMTPA id A02E76800E3; Mon, 9 Feb 2015 18:44:03 -0500 (EST)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <54CFA75F.2040605@andyet.net>
Date: Mon, 09 Feb 2015 15:44:02 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <31B110BC-C8B0-48B0-BD24-2F7F7DCA1ED6@cooperw.in>
References: <0C205FB7-2C6B-4773-830F-B8354CC65A75@cooperw.in> <54CFA75F.2040605@andyet.net>
To: Peter Saint-Andre - &yet <peter@andyet.net>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/stox/NN5qlwFkG2vW3Jh63kfxWOYBttg>
Cc: stox@ietf.org
Subject: Re: [Stox] AD evaluation: draft-ietf-stox-chat-08
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: Mon, 09 Feb 2015 23:44:08 -0000

On Feb 2, 2015, at 8:35 AM, Peter Saint-Andre - &yet <peter@andyet.net> wrote:

> On 1/31/15 5:09 PM, Alissa Cooper wrote:
> 
>> = Section 7 = Is all of the delivery report behavior meant to be
>> entirely optional to support, or should there be some normative
>> requirements listed in this section?
> 
> IMHO this is entirely optional (as with Section 6).

I think the difference between Section 6 and Section 7 is that Section 6 at least gives a little narrative description of how to do the mapping for composing notifications, whereas in Section 7 there is no such description, it’s just illustrated by examples. So I would suggest adding a sentence or two that generically describes what the gateway in each direction should do to map an MSRP REPORT to an XMPP message receipt request/response and vice versa. This is obviously a small thing but seems like good practice. This can be dealt with during IETF LC.

Ben has sent comments on this draft and I’d like to see how that discussion resolves before issuing the IETF LC.

Thanks,
Alissa 

> 
>> = Section 4 = "The XMPP-to-SIP gateway at the XMPP server would then
>> initiate an MSRP session with Romeo on Juliet's behalf (since there
>> is no reliable way for the gateway to determine if Romeo's client
>> supports MSRP, it simply needs to guess).”
>> 
>> “Guessing” makes it sound like the gateway might use heuristics or
>> some such to determine whether to initiate an MSRP session, and that
>> in some cases it might not initiate a session. Would it be more
>> accurate to say that MSRP session initiation may yield an error since
>> there is no reliable way for the gateway to determine if Romeo's
>> client supports MSRP?
> 
> Yes, that's better.
> 
> Peter
> 
> -- 
> Peter Saint-Andre
> https://andyet.com/