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

Paul Kyzivat <pkyzivat@cisco.com> Tue, 28 September 2010 12:38 UTC

Return-Path: <pkyzivat@cisco.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 330283A6C7D for <martini@core3.amsl.com>; Tue, 28 Sep 2010 05:38:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.487
X-Spam-Level:
X-Spam-Status: No, score=-110.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 cxJcje6rGTxE for <martini@core3.amsl.com>; Tue, 28 Sep 2010 05:38:41 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id C871F3A6A9B for <martini@ietf.org>; Tue, 28 Sep 2010 05:38:40 -0700 (PDT)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAMJ+oUxAZnwM/2dsb2JhbACiHHGsHZx4hUQEijqCfw
X-IronPort-AV: E=Sophos;i="4.57,247,1283731200"; d="scan'208";a="164507644"
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 28 Sep 2010 12:39:21 +0000
Received: from [161.44.174.118] (dhcp-161-44-174-118.cisco.com [161.44.174.118]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o8SCdLBv007925; Tue, 28 Sep 2010 12:39:21 GMT
Message-ID: <4CA1E1F9.1050905@cisco.com>
Date: Tue, 28 Sep 2010 08:39:21 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3
MIME-Version: 1.0
To: "Elwell, John" <john.elwell@siemens-enterprise.com>
References: <A444A0F8084434499206E78C106220CA01C81C2B32@MCHP058A.global-ad.net> <4CA0FC0B.5070703@nostrum.com> <4CA10120.8030601@cisco.com> <A444A0F8084434499206E78C106220CA01C81C2BFA@MCHP058A.global-ad.net>
In-Reply-To: <A444A0F8084434499206E78C106220CA01C81C2BFA@MCHP058A.global-ad.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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 12:38:43 -0000

On 9/28/2010 2:12 AM, Elwell, John wrote:
> 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.

Yeah, me too. I was really just pointing out the idiocy of reputed 
objections to such language. But hopefully they are just urban legends.

	Thanks,
	Paul


> 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
>>>
>>