Re: [martini] New text for gin section 7.1.1 first paragraph

"Elwell, John" <john.elwell@siemens-enterprise.com> Tue, 28 September 2010 06:12 UTC

Return-Path: <john.elwell@siemens-enterprise.com>
X-Original-To: martini@core3.amsl.com
Delivered-To: martini@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62CB63A6B23 for <martini@core3.amsl.com>; Mon, 27 Sep 2010 23:12:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.633
X-Spam-Level:
X-Spam-Status: No, score=-102.633 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kheGsb-pAhqt for <martini@core3.amsl.com>; Mon, 27 Sep 2010 23:12:03 -0700 (PDT)
Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id C66623A69F2 for <martini@ietf.org>; Mon, 27 Sep 2010 23:12:02 -0700 (PDT)
Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1647297; Tue, 28 Sep 2010 08:12:42 +0200
Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 2A49723F0278; Tue, 28 Sep 2010 08:12:42 +0200 (CEST)
Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 28 Sep 2010 08:12:42 +0200
From: "Elwell, John" <john.elwell@siemens-enterprise.com>
To: Paul Kyzivat <pkyzivat@cisco.com>, Adam Roach <adam@nostrum.com>
Date: Tue, 28 Sep 2010 08:12:40 +0200
Thread-Topic: [martini] New text for gin section 7.1.1 first paragraph
Thread-Index: ActehDDw4/T+6IgFSCehUDRfTH/V2gAT4YAQ
Message-ID: <A444A0F8084434499206E78C106220CA01C81C2BFA@MCHP058A.global-ad.net>
References: <A444A0F8084434499206E78C106220CA01C81C2B32@MCHP058A.global-ad.net> <4CA0FC0B.5070703@nostrum.com> <4CA10120.8030601@cisco.com>
In-Reply-To: <4CA10120.8030601@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "martini@ietf.org" <martini@ietf.org>
Subject: Re: [martini] New text for gin section 7.1.1 first paragraph
X-BeenThere: martini@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/martini>
List-Post: <mailto:martini@ietf.org>
List-Help: <mailto:martini-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Sep 2010 06:12:04 -0000

Paul,

One could rephrase it in terms of "Unless .... MUST", but I tend to prefer a style of stating the normal case first, and any exceptions afterwards. As others who have responded seem to be in agreement with the text as it stands, let's leave it as is.

John 

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] 
> Sent: 27 September 2010 21:40
> To: Adam Roach
> Cc: Elwell, John; martini@ietf.org
> Subject: Re: [martini] New text for gin section 7.1.1 first paragraph
> 
> I'm also happy with this text.
> 
> Now we get to confront the language police: is "... MUST ... unless P 
> ..." acceptable? (I'm pretty sure the logically equivalent "... if !P 
> then MUST ..." has to be ok.)
> 
> 	Thanks,
> 	Paul
> 
> On 9/27/2010 4:18 PM, Adam Roach wrote:
> >
> > I support this proposed text. I believe it strikes a good balance
> > between mandating GRUUs and providing networks with alternative
> > architectures the ability to implement routing as they see fit.
> >
> > /a
> >
> > On 9/27/10 2:30 PM, Elwell, John wrote:
> >> As actioned on this evening's call, here is my proposed text:
> >>
> >> "An SSP needs to provide a means of assigning globally routable
> >> contact URIs to UAs that have been registered using the bulk
> >> registration mechanism specified in this document, thereby allowing
> >> other entities to address out-of-dialog requests to those UAs. To
> >> achieve this, an SSP MUST support the public GRUU 
> mechanism described
> >> in this section, unless the SSP has other means of 
> providing globally
> >> routable contact URIs (e.g., by acting as a B2BUA and performing
> >> mapping between SIP-PBX-provided local contact URIs and 
> SSP-provided
> >> globally routable contact URIs)."
> >>
> >> John
> >> _______________________________________________
> >> martini mailing list
> >> martini@ietf.org
> >> https://www.ietf.org/mailman/listinfo/martini
> >
> > _______________________________________________
> > martini mailing list
> > martini@ietf.org
> > https://www.ietf.org/mailman/listinfo/martini
> >
>