Re: [iucg] [happiana] New Version Notification for draft-leiba-iana-policy-update-00.txt

JFC Morfin <jefsey@jefsey.com> Wed, 28 September 2011 21:27 UTC

Return-Path: <jefsey@jefsey.com>
X-Original-To: iucg@ietfa.amsl.com
Delivered-To: iucg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A01321F8DCF; Wed, 28 Sep 2011 14:27:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.028
X-Spam-Level:
X-Spam-Status: No, score=-102.028 tagged_above=-999 required=5 tests=[AWL=0.570, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zj2FBWA8yAoE; Wed, 28 Sep 2011 14:27:57 -0700 (PDT)
Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id 1C11E21F8D89; Wed, 28 Sep 2011 14:27:57 -0700 (PDT)
Received: from 191.39-227-89.dsl.completel.net ([89.227.39.191]:49188 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from <jefsey@jefsey.com>) id 1R91hm-0003oH-5w; Wed, 28 Sep 2011 14:30:24 -0700
Message-Id: <7.0.1.0.2.20110928160216.0b525188@jefsey.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0
Date: Wed, 28 Sep 2011 23:35:05 +0200
To: happiana@ietf.org
From: JFC Morfin <jefsey@jefsey.com>
In-Reply-To: <6.2.5.6.2.20110927224537.09b1f9b0@resistor.net>
References: <20110927155722.26914.33845.idtracker@ietfa.amsl.com> <CALaySJ+p=-TRvieV_hgMxWTXaSMxUWQqZR+1xymdjr1M7mMhBg@mail.gmail.com> <C68CB012D9182D408CED7B884F441D4D05D47F8C0A@nambxv01a.corp.adobe.com> <6.2.5.6.2.20110927224537.09b1f9b0@resistor.net>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_1109455850==.ALT"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - montage2.altserver.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jefsey.com
X-Source:
X-Source-Args:
X-Source-Dir:
Cc: iucg@ietf.org
Subject: Re: [iucg] [happiana] New Version Notification for draft-leiba-iana-policy-update-00.txt
X-BeenThere: iucg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: internet users contributing group <iucg@ietf.org>
List-Id: internet users contributing group <iucg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iucg>, <mailto:iucg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/iucg>
List-Post: <mailto:iucg@ietf.org>
List-Help: <mailto:iucg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iucg>, <mailto:iucg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Sep 2011 21:27:58 -0000

At 08:04 28/09/2011, SM wrote:
>At 15:54 27-09-2011, Larry Masinter wrote:
>>I have heard people asking for IANA to manage registration 
>>information in a data format (such as XML). Should documents that 
>>establish a registry also establish the data format?
>
>No. :-)
>
>In Section 3:
>
>   "Accordingly, document developers need to anticipate this and include
>    a justification for the chosen policy in the document along with the
>    documentation of the choice."
>
>I like the idea.  I am wary of this being misinterpreted as giving 
>more weight to IANA Considerations instead of more thought to it.

The Internet is a part of the whole digital ecosystem (WDE). As such 
it should converge with other registries documenting the WDE or being 
used through the WDE. This calls for the IANA to also capitilize on 
the JTC1/SC32/WG2 experience and study the interest of becoming at 
least ISO 11179 conformant. This should lead Barry's I_D is to be 
"ported" into an ISO 11179 context  (concepts, terminology, 
procedures, I/O formats, creation, relation with information 
provider,  graded reviewers, etc.). And then consider  how it would 
better/lesser fit the IANA needs.

This  was discussed at the langtag registry definition time. The 
langtag registry by its size is most of the IANA registry. It did not 
went through beacause the langtag registry was a new registry and the 
WG's charter did not focus on what ISO 11179 would have brought.

I wish to quote an excellent mail on the matter by Debbie Garside 
(NB. I defeated her FDIS 3166-1 which was an uncorrect political 
move, but analyzing ISO 11179 conformance was a right architectural move).

>"Debbie Garside" <debbie <at> ictmarketing.co.uk>
>06/27/2006 01:22 AM
>
>To "'LTRU Working Group'" <ltru <at> ietf.org>
>Object: [Ltru] Preliminary Investigation into Application of ISO 11179
>
>Findings of a preliminary investigation into the application of ISO 11179 to
>the RFC3066bis Registry
>
>Cost
>Initial investigations suggest that ISO 11179 can be applied to the Registry
>at a base level for very little cost.  The main cost is in mapping the ISO
>11179 terminology to the existing Registry terminology and a number of
>additional data elements would be required.  The Registry already
>incorporates a system of metadata elements that are consistent with the
>model presented within ISO 11179.
>
>In particular the value of the following aspects of ISO 11179-6 should be
>investigated:
>
>Identification
>The attributes registration authority identifier (RAI), data identifier
>(DI), and version identifier (VI) constitute the international registration
>data identifier (IRDI). At least one IRDI is required for an administered
>item.
>
>Data identifiers are assigned by a Registration Authority; data identifiers
>shall be unique within the domain of a Registration Authority.
>
>Requirements for a Registration Authority, and a discussion of the IRDI,
>appear in ISO/IEC 11179-6.
>
>As each Registration Authority may determine its own DI assignment scheme,
>there is no guarantee that the DI by itself will uniquely identify an
>administered item. For example, if two authorities both use sequential
>6-digit numbers, there may be two administered items with the same DI's;
>however, the administered items will almost certainly not be the same.
>
>If one administered item appears in two registers, it will have two DI's.
>Therefore, both the DI and the RAI are necessary for identification of an
>administered item.
>
>If particular attributes of an administered item change, then a new version
>of the administered item shall be created and registered. The registrar
>shall determine these attributes. In such a case, a VI is required to
>complete the unique identification of an administered item.
>
>For further guidance, see ISO/IEC 11179-6.
>
>An IRDI can serve as a key when exchanging data among information systems,
>organizations, or other parties who wish to share a specific administered
>item, but might not utilize the same names or contexts.
>
>ISO/IEC 11179 does not specify the format or content of a unique DI.
>
>The IETF (or LTRU) would need to apply for an International Code Designator
>(ICD) - a four integer code; this coupled with the organization name as well
>as a "department" identifier (OPI) becomes the IRDI e.g. 1234.IETF.LTRU.
>The ICD would be registered by the RA of ISO/IEC 6523 Organization Codes as
>Registration Authority Identifier which is currently BSI.
>
>Implications for the LTRU Registry
>The DI (or UI - Unique Identifier) cannot be the Subtag as there are already
>conflicting Subtags within the registry (e.g. cy/CY).  It is more preferable
>that the unique identifier be the chosen language/country/script name
>(please note, this is not the preferred name).  This would fit with the
>current ISO 639-3, -5 and -6 models and open the Registry to adoption by
>meta-data knowledge grids. (I will take a good look at the naming
>conventions within ISO 3166-1 at a later date but prior to publication of
>FDIS 3166-1).
>
>Anomalies within ISO naming conventions of standards issued prior to the
>adoption of ISO 11179 can be dealt with on a case by case basis via set
>rules.
>
>The Subtag would become a "Representation" with the name being the unique
>"Data Identifier". This would involve having a "Primary Description" which
>would form the DI.
>
>In reviewing the "Required Metadata Attributes" for a "Preferred Standard"
>Status administered item, preliminary investigations reveal no serious
>additional requirements other than those already mentioned here. Some
>manipulation and interpretation of registry data and standard mandatory
>requirements would be required but no difficulties are envisaged. I would
>refer the WG to ISO/IEC 11179-6:2005(E); Table B-8 (p.34)
>
>Benefits
>The ISO 11179 model allows for there being conflicting codes between
>different meta-data registries in conformity with ISO 11179; that is part of
>the conceptual model.  ("in conformity with" is correct - there are
>essential parts of the standard).
>
>In essence, the ISO 11179 meta-model supports linkage to other ISO 11179
>conformant meta-data registries thus facilitating data exchange/interchange
>whilst giving the LTRU Registry ownership of the data elements contained
>therein - they become LTRU elements giving room for manoeuvre should ISO get
>it wrong.
>
>This will make language tags more meaningful in the future.  The key word
>here is "linkage".  ISO 11179 conformant meta-data registries facilitate the
>creation of knowledge grids, grid computing and the semantic web!
>
>Conclusion
>At first glance the cost/value ratio favours ISO 11179; there appears to be
>very little cost yet the true benefits of future interoperability and data
>exchange are unknown.
>
>It is recommended that further investigation be conducted before application
>of ISO 11179 can be discussed at WG level.
>
>Further benefits with regard to data interchange should be explored.
>
>It is further recommended that the "investigation into application of ISO
>11179 Meta Data Registries to the Registry and its registration procedures
>be conducted by nominated members of the WG with a view to application" be
>added to the new LTRU Charter.
>
>Best regards
>Debbie Garside

More information on ISO 11179  MetaData registries:
http://metadata-stds.org/
http://en.wikipedia.org/wiki/ISO/IEC_11179

Best
jfc