Re: [Simple] draft-ietf-simple-msrp-cema-05 WGLC comments - Section 4 and editorials (Ben)

Ben Campbell <ben@nostrum.com> Thu, 31 May 2012 18:47 UTC

Return-Path: <ben@nostrum.com>
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 53BCF11E8086 for <simple@ietfa.amsl.com>; Thu, 31 May 2012 11:47:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level:
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOir-OmDQa65 for <simple@ietfa.amsl.com>; Thu, 31 May 2012 11:47:55 -0700 (PDT)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id A155711E8081 for <simple@ietf.org>; Thu, 31 May 2012 11:47:55 -0700 (PDT)
Received: from [10.0.1.33] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q4VIlm5h093575 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 31 May 2012 13:47:49 -0500 (CDT) (envelope-from ben@nostrum.com)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset="us-ascii"
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C459A338F@ESESSCMS0356.eemea.ericsson.se>
Date: Thu, 31 May 2012 13:47:48 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <5F1730E7-0C2D-49F1-8C8E-B5B065BABF90@nostrum.com>
References: <7F2072F1E0DE894DA4B517B93C6A05852C444A0D0C@ESESSCMS0356.eemea.ericsson.se> <2CDCC2EF-B5AF-4101-857C-0B9E42F381A8@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05852C459128EF@ESESSCMS0356.eemea.ericsson.se> <E5006332-B299-4407-BAE7-09E0D1B1C2F9@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05852C459A338F@ESESSCMS0356.eemea.ericsson.se>
To: Christer Holmberg <christer.holmberg@ericsson.com>
X-Mailer: Apple Mail (2.1278)
Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism)
Cc: "draft-ietf-simple-msrp-cema.all@tools.ietf.org" <draft-ietf-simple-msrp-cema.all@tools.ietf.org>, Simple WG <simple@ietf.org>
Subject: Re: [Simple] draft-ietf-simple-msrp-cema-05 WGLC comments - Section 4 and editorials (Ben)
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: Thu, 31 May 2012 18:47:56 -0000

On May 31, 2012, at 4:46 AM, Christer Holmberg wrote:

[...]

>> 
>> I don't think the definition needs to describe the entire process. could we just say "name of the peer", perhaps with a disclaimer that that the meaning of "name" is as described by the protocol?
> 
> So, something like:
> 
> 
> 	"Name Based Authentication: An authentication method in which an 
> 	endpoint receives an X.509 certificate from its peer as part of the 
> 	TLS authentication. The endpoint validates that a chain of issuers exists 
> 	from the certificate to a trusted certification authority, and that the 
> 	certificate contains the name (as indicated in SIP/SDP) of the 
> 	peer."
> 
> 

Works for me.


> ---------------------

[...]

>> There are situations described in section 4 where an endpoint can attempt to use CEMA even if the other party did not 
>> indicate support. Do we assume the middlebox is also going to try to figure out those cases, or is it purely going to look for the
>> CEMA tag? If the second,  does it require both parties to include it?
> 
> Ok, now I understand :)
> 
> The Middlebox does not need to be aware of different cases. It only looks for the CEMA tag in the offer.
> 
> Then, if the answerer does not support CEMA, and CEMA cannot be used (based on the criteria in section 4.2), the offerer will send a new offer, without the CEMA tag.

Okay.