Re: [Ltru] Last open item

"Randy Presuhn" <randy_presuhn@mindspring.com> Wed, 16 April 2008 19:03 UTC

Return-Path: <ltru-bounces@ietf.org>
X-Original-To: ltru-archive@megatron.ietf.org
Delivered-To: ietfarch-ltru-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E19328C1D6; Wed, 16 Apr 2008 12:03:56 -0700 (PDT)
X-Original-To: ltru@core3.amsl.com
Delivered-To: ltru@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 360143A6F7A for <ltru@core3.amsl.com>; Wed, 16 Apr 2008 12:03:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.37
X-Spam-Level:
X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[AWL=0.229, 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 JFSsL8ewt5WI for <ltru@core3.amsl.com>; Wed, 16 Apr 2008 12:03:53 -0700 (PDT)
Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 47C4828C4B0 for <ltru@ietf.org>; Wed, 16 Apr 2008 12:03:20 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=r/VUJTNfXXwWt91CCLa9Y1CCA/hdJeCMcA9pZro1uv/ZDltlVezYp0/eiIsFIBHx; 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 [68.166.38.82] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <randy_presuhn@mindspring.com>) id 1JmCvE-0006OQ-1X for ltru@ietf.org; Wed, 16 Apr 2008 15:03:56 -0400
Message-ID: <002701c89fec$59799e60$6801a8c0@oemcomputer>
From: Randy Presuhn <randy_presuhn@mindspring.com>
To: LTRU Working Group <ltru@ietf.org>
References: <30b660a20804140815w5d56933auefbdccdcbdfe034b@mail.gmail.com> <001e01c89e4b$897c0000$6801a8c0@oemcomputer> <20080414193212.GI28132@mercury.ccil.org> <002601c89e94$80c98ce0$6801a8c0@oemcomputer> <20080415021154.GK19045@mercury.ccil.org> <001001c89ea2$29a61560$6801a8c0@oemcomputer> <20080415170448.GJ28132@mercury.ccil.org> <002601c89f17$aff089a0$6801a8c0@oemcomputer> <30b660a20804151059m2e82e773y5a9b0c4f2aab883a@mail.gmail.com> <000b01c89f1d$7abf8960$6801a8c0@oemcomputer> <20080416104620.GA10693@nic.fr>
Date: Wed, 16 Apr 2008 12:04:43 -0600
MIME-Version: 1.0
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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8885d2a9c731cc8911711d4fdd77251c12953808e17bdb4170d350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 68.166.38.82
Subject: Re: [Ltru] Last open item
X-BeenThere: ltru@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Language Tag Registry Update working group discussion list <ltru.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ltru>
List-Post: <mailto:ltru@ietf.org>
List-Help: <mailto:ltru-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ltru-bounces@ietf.org
Errors-To: ltru-bounces@ietf.org

Hi -

> From: "Stephane Bortzmeyer" <bortzmeyer@nic.fr>
> To: "Randy Presuhn" <randy_presuhn@mindspring.com>
> Cc: "LTRU Working Group" <ltru@ietf.org>
> Sent: Wednesday, April 16, 2008 4:46 AM
> Subject: Re: Last open item
...
> Every standard which performs canonicalization has the same
> issues. For instance, NFC in Unicode is not stable (a string of
> Unicode characters which is in NFC form today may not be in the
> future). You have to add a few constraints, as the RFC 5198 does, to
> have a "stable NFC".

Wandering close to off-topic...

"Every" is a bit of an over-statement.

Some sets of ASN.1 encoding rules don't have this problem.
If one is worried about instance naming (as in SNMP, SMUX, 
AgentX or with CMIP in a sub-agent architecture) having an
utterly stable canonical form is essential.  The SNMP-family
protocols are particularly dependent on there being exactly one
representation for an instance name.  Consider the GetNext 
and GetBulk operations, for example.  It is such a strong
assumption that the topic never even comes up in most
discussions of these protocols.

But since I'm clearly the only one on this list who thinks this weak
sense of "canonical" is broken, I've already given up arguing the point.

Randy

_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www.ietf.org/mailman/listinfo/ltru