Re: [Ltru] Suggested text for future compatibility of registryprocessors.
"Randy Presuhn" <randy_presuhn@mindspring.com> Mon, 02 July 2007 00:15 UTC
Return-path: <ltru-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I59Zv-0006pc-6i; Sun, 01 Jul 2007 20:15:43 -0400
Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I59Zt-0006nx-Hq for ltru-confirm+ok@megatron.ietf.org; Sun, 01 Jul 2007 20:15:41 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I59Zt-0006mN-5G for ltru@ietf.org; Sun, 01 Jul 2007 20:15:41 -0400
Received: from elasmtp-curtail.atl.sa.earthlink.net ([209.86.89.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I59Zp-000894-SW for ltru@ietf.org; Sun, 01 Jul 2007 20:15:41 -0400
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=ST2XdryDh6eV3Y1R79HLeYh6dU1QTMseqOU7xBzUkh3sAWqU6RI2FenrkxSlHtK3; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [64.105.34.104] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1I59Zo-0006Xl-T4 for ltru@ietf.org; Sun, 01 Jul 2007 20:15:37 -0400
Message-ID: <000701c7bc3e$3517e0a0$6601a8c0@oemcomputer>
From: Randy Presuhn <randy_presuhn@mindspring.com>
To: LTRU Working Group <ltru@ietf.org>
References: <30b660a20707011618m67fe32e6n73e81f8d3bddd69d@mail.gmail.com> <003f01c7bc39$08708ca0$6601a8c0@oemcomputer> <30b660a20707011655y4c99bc31h3f1e2d63d36a91fd@mail.gmail.com>
Subject: Re: [Ltru] Suggested text for future compatibility of registryprocessors.
Date: Sun, 01 Jul 2007 17:16:15 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a9356ee67a26f632b86eed6ae115164658a53350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 64.105.34.104
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
X-BeenThere: ltru@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Language Tag Registry Update working group discussion list <ltru.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ltru>
List-Post: <mailto:ltru@ietf.org>
List-Help: <mailto:ltru-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=subscribe>
Errors-To: ltru-bounces@ietf.org
Hi - As a technical contributor... > From: "Mark Davis" <mark.davis@icu-project.org> > To: "Randy Presuhn" <randy_presuhn@mindspring.com> > Cc: "LTRU Working Group" <ltru@ietf.org> > Sent: Sunday, July 01, 2007 4:55 PM > Subject: Re: [Ltru] Suggested text for future compatibility of registryprocessors. > > Your changes sound fine by me. I do have a question. I thought MAY was only > capitalized when it was in reference to conformance to this document. But in > that statement it doesn't seem to apply: it doesn't appear that we in this > document can make any conformance promises (positive or negative) about > future versions since that is entirely in the hands of the IETF. ... I was looking at it from a protocol specification perspective. When defining an extensible protocol, using SHOULD, MUST, etc. makes sense when specifying the nature of permissible extensions. If we wanted to be really pedantic, for example, we could spell out that future extensions MUST NOT violate the syntax established for "record" in the ABNF. (If we were indeed going to make a commitment to forward compatibility in the registry format. At this point, we haven't constrained ourselves in this way, and please don't read this example as an argument that we should constrain ourselves in this way. Indeed, I think we really need to discourage implementations (other than very specialized developer tools) from reading the registry itself, in much the same way as network management applications don't dynamically query the IANA enterprise number assignments.) Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru
- [Ltru] Suggested text for future compatibility of… Mark Davis
- Re: [Ltru] Suggested text for future compatibilit… Randy Presuhn
- Re: [Ltru] Suggested text for future compatibilit… Mark Davis
- Re: [Ltru] Suggested text for future compatibilit… Randy Presuhn
- Re: [Ltru] Suggested text for future compatibilit… Addison Phillips
- Re: [Ltru] Suggested text for future compatibilit… Mark Davis
- [Ltru] Re: Suggested text for future compatibilit… Doug Ewell
- Re: [Ltru] Re: Suggested text for future compatib… John Cowan
- Re: [Ltru] Re: Suggested text for future compatib… Doug Ewell
- [Ltru] Re: Macrolanguage and extlang Doug Ewell
- Re: [Ltru] Re: Macrolanguage and extlang John Cowan
- [Ltru] Re: Macrolanguage and extlang Doug Ewell
- Re: [Ltru] Re: Macrolanguage and extlang Mark Davis
- Re: [Ltru] Re: Macrolanguage and extlang Doug Ewell
- [Ltru] Re: Suggested text for future compatibilit… Stephane Bortzmeyer
- [Ltru] Re: Macrolanguage and extlang Stephane Bortzmeyer
- RE: [Ltru] Re: Macrolanguage and extlang Peter Constable
- Re: [Ltru] Re: Macrolanguage and extlang Mark Davis
- Re: [Ltru] Re: Macrolanguage and extlang Addison Phillips
- Re: [Ltru] Re: Macrolanguage and extlang Randy Presuhn
- Re: [Ltru] Re: Macrolanguage and extlang John Cowan
- Re: [Ltru] Re: Macrolanguage and extlang Doug Ewell
- [Ltru] Re: Macrolanguage and extlang Doug Ewell
- Re: [Ltru] Re: Macrolanguage and extlang John Cowan
- RE: [Ltru] Re: Macrolanguage and extlang Kent Karlsson
- Re: [Ltru] Re: Macrolanguage and extlang John Cowan