Re: [Simple] I-D Action: draft-ietf-simple-chat-17.txt

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 19 November 2012 22:34 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: simple@ietfa.amsl.com
Delivered-To: simple@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B68121F8597 for <simple@ietfa.amsl.com>; Mon, 19 Nov 2012 14:34:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.399
X-Spam-Level:
X-Spam-Status: No, score=-0.399 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2bnrQ303Xa0 for <simple@ietfa.amsl.com>; Mon, 19 Nov 2012 14:34:47 -0800 (PST)
Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id F27BA21F858B for <simple@ietf.org>; Mon, 19 Nov 2012 14:34:46 -0800 (PST)
Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta04.westchester.pa.mail.comcast.net with comcast id RaZn1k00517dt5G54aamWY; Mon, 19 Nov 2012 22:34:46 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id Raal1k00i3ZTu2S3ZaaljA; Mon, 19 Nov 2012 22:34:46 +0000
Message-ID: <50AAB403.8090509@alum.mit.edu>
Date: Mon, 19 Nov 2012 17:34:43 -0500
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: simple@ietf.org
References: <20121117160611.10411.74381.idtracker@ietfa.amsl.com> <50A7BBA9.7040904@ericsson.com> <014CCF1E-A698-4351-9246-6CBBC8B37BAD@nostrum.com>
In-Reply-To: <014CCF1E-A698-4351-9246-6CBBC8B37BAD@nostrum.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [Simple] I-D Action: draft-ietf-simple-chat-17.txt
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions <simple.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/simple>, <mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/simple>, <mailto:simple-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Nov 2012 22:34:47 -0000

On 11/19/12 4:12 PM, Ben Campbell wrote:
> Thanks Miguel. I think this version is much improved. But of course, here's a few questions and comments:
>
> Questions:
>
> 5.2 : There is new normative language in section 5.2 concerning the use of "accept-types" and "accept-wrapped-types" Do I read it correctly that and endpoint SHOULD (i.e. RECOMMENDED) include accept-wrapped-types, and a focus MAY do so? Do we allow either to include anything _other_ than message/cpim in accept-types?  If not, what does it mean to include only message/CPIM in "accept-types" and not include "accept-wrapped-types"?
>
> The last paragraph of 5.2 says that the focus must inform the switch of the chat room capabilities of each participant, and that it does this with the SDP "chatroom" attribute. Do we assume anything about how the focus and switch communicate? I thought the chatroom attribute was more about how the focus communicates this with _endpoints_.

This was in response to comments I made some time ago.
The point was to future-proof this, so that if in the future there is a 
new type (say message/cpim++) that something that implements that will 
be able to indicate support for both message/cpim and message/cpim++ and 
still be conforming to this spec.

(Of course, if both ends then support message/cpim++ and decide to use 
it, then they will cease to be operating in accord with this spec. 
Instead they will be following some new spec that calls for use of 
message/cpim++.)

	Thanks,
	Paul