Re: [Iptel] draft-ietf-iptel-reg-05
lconroy <lconroy@insensate.co.uk> Fri, 16 May 2008 16:18 UTC
Return-Path: <iptel-bounces@ietf.org>
X-Original-To: iptel-archive@megatron.ietf.org
Delivered-To: ietfarch-iptel-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9B5E3A6AD1; Fri, 16 May 2008 09:18:26 -0700 (PDT)
X-Original-To: iptel@core3.amsl.com
Delivered-To: iptel@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F15E83A67B7 for <iptel@core3.amsl.com>; Fri, 16 May 2008 09:18:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 DYTz-J2vCly8 for <iptel@core3.amsl.com>; Fri, 16 May 2008 09:18:20 -0700 (PDT)
Received: from insensate.co.uk (norman.insensate.co.uk [213.152.49.123]) by core3.amsl.com (Postfix) with ESMTP id 6F4603A6AD1 for <iptel@ietf.org>; Fri, 16 May 2008 09:18:16 -0700 (PDT)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id B79949812F; Fri, 16 May 2008 17:18:10 +0100 (BST)
In-Reply-To: <482DACBE.2090505@alcatel-lucent.com>
References: <C6105D088233254CA462CEE2B399CD7101FACEEF@STNTEXCH12.cis.neustar.com> <482DACBE.2090505@alcatel-lucent.com>
Mime-Version: 1.0 (Apple Message framework v753)
Message-Id: <DAD9F6A6-19EE-4D92-A221-0599FBA09DD3@insensate.co.uk>
From: lconroy <lconroy@insensate.co.uk>
Date: Fri, 16 May 2008 17:18:08 +0100
To: "Vijay K.Gurbani" <vkg@alcatel-lucent.com>
X-Mailer: Apple Mail (2.753)
Cc: fluffy@cisco.com, iptel@ietf.org, "Yu, James" <james.yu@neustar.biz>
Subject: Re: [Iptel] draft-ietf-iptel-reg-05
X-BeenThere: iptel@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IP Telephony <iptel.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/iptel>, <mailto:iptel-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/iptel>
List-Post: <mailto:iptel@ietf.org>
List-Help: <mailto:iptel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iptel>, <mailto:iptel-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: iptel-bounces@ietf.org
Errors-To: iptel-bounces@ietf.org
Hi Vijay, folks, Your/the IESG's solution is fine - it is even clearer, which is always good. I look forward to seeing this as an RFC real soon now :). all the best, Lawrence On 16 May 2008, at 16:48, Vijay K. Gurbani wrote: > Yu, James wrote: >> Since the purpose of the I-D is to register "values" to avoid >> duplicated assignments, any tel URI parameter that does not require >> registration of predefined value(s) should be assigned "No" in Table >> 1. > [...] > > And Lawrence Conroy wrote: >> Changing things now does not help, generates more work, and adds >> precisely nothing - if someone isn't going to read the guidance text, >> then chaning the logic of that text (and the table) isn't going to >> help. > > James: By and large, I concur with Lawrence. However, during the IESG > review, there was a COMMENT raised to clarify the table contents a > bit more. Note that this was a COMMENT, and not a DISCUSS; so > pedantically we could have left the table as-is; but I believe that > addressing the COMMENT does do some good, and it may alleviate your > problem as well. The suggested -- and accepted -- text does not > deviate from what is currently there in -05, just uses different > words to render equivalent impact more cleanly. > > Here is the change that was agreed to: > > Section 3: > OLD > > Accordingly, the tel URI parameter registry contains a column > that > indicates whether or not each parameter only accepts a set of > predefined values. The column can contain "Yes", or "No". A > value > of "Yes" in the column implies that certain predefined values > exist > for this parameter and the accompanying RFC or other permanent > and > readily available public specification should be consulted to > find > out the accepted set of values. A value of "No" in the column > implies that the parameter is used either as a flag, or does not > have a set of predefined values. The accompanying RFC or other > permanent and readily available public specification should > provide > more information on the semantics of the parameter. > > NEW: > > Accordingly, the tel URI parameter registry contains a column > that > indicates whether or not each parameter accepts a value. The > column may contain "No value" or "Constrained". A "Constrained" > in the column implies that certain predefined values exist for > this parameter and the accompanying RFC or other permanent and > readily available public specification should be consulted to > find > out the accepted set of values. A "No Value" in the column > implies that the parameter is used either as a flag, or does not > have a set of predefined values. The accompanying RFC or other > permanent and readily available public specification should > provide > more information on the semantics of the parameter. > > and accordingly, change the table as follows: > > OLD: > > Parameter Name Predefined Values Reference > -------------- ----------------- --------- > isub Yes [RFC 3966] > isub-encoding Yes [RFC 4715] > ext Yes [RFC 3966] > phone-context Yes [RFC 3966] > enumdi No [RFC 4759] > npdi No [RFC 4694] > rn Yes [RFC 4694] > rn-context Yes [RFC 4694] > cic Yes [RFC 4694] > cic-context Yes [RFC 4694] > tgrp Yes [RFC 4904] > trunk-context Yes [RFC 4904] > > NEW: > > Parameter Name Value Type Reference > -------------- ------------ --------- > isub Constrained [RFC 3966] > isub-encoding Constrained [RFC 4715] > ext Constrained [RFC 3966] > phone-context Constrained [RFC 3966] > enumdi No value [RFC 4759] > npdi No value [RFC 4694] > rn Constrained [RFC 4694] > rn-context Constrained [RFC 4694] > cic Constrained [RFC 4694] > cic-context Constrained [RFC 4694] > tgrp Constrained [RFC 4904] > trunk-context Constrained [RFC 4904] > > Thanks, > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > WWW: http://www.alcatel-lucent.com/bell-labs > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www.ietf.org/mailman/listinfo/iptel _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel
- [Iptel] draft-ietf-iptel-reg-05 Yu, James
- Re: [Iptel] draft-ietf-iptel-reg-05 lconroy
- Re: [Iptel] draft-ietf-iptel-reg-05 Vijay K. Gurbani
- Re: [Iptel] draft-ietf-iptel-reg-05 lconroy