[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Submission draft-goodwin-iso-urn-00.txt -- application for a formal NID
We have converted the text to XML and passed it through your XML converter.
Hopefully it should now conform to all rules.
Please let us know asap if there are any further problems.
Thanks
Jo Goodwin
-----Original Message-----
> Thanks but I'm rather confused by this latest message.
>
> The other day I received a mail (see attachment) that said "For the
> record, I think the document is complete and correct.".
>
> Also, your rules say 72 characters per line -- which is what I set the
> document to (see attached).
>
> Could you please explain a little better what I now need to do.
>
> Thanks
>
> Joanna Goodwin
>
> -----Original Message-----
> From: ids at ietf.org [mailto:ids at ietf.org]
> Sent: 2006-04-04 19:44
> To: goodwin at iso.org
> Cc: mckinley at iso.org; 'SC'; 'Holger Apel'; rinta-filppula at iso.org
> Subject: RE: Submission draft-goodwin-iso-urn-00.txt -- application
> for a formal NID
>
> The actual document formating (the line length is too long). Please
> format the file and resubmit. Thank you.
>
>
>
>> Please find attached a reformatted version for application for a
>> formal NID.
>>
>> As before, if there is anything else that needs to be done to assure
>> submission could you please let us know as soon as possible. If there
>> are any further problems, would it possible to list all of them in
>> one go -- I think it would be quicker for us both.
>>
>> With best wishes
>>
>> Joanna Goodwin
>>
>> -----Original Message-----
>> From: ids at ietf.org [mailto:ids at ietf.org]
>> Sent: 2006-03-29 22:51
>> To: goodwin at iso.org
>> Cc: mckinley at iso.org; 'SC'; 'Holger Apel'; rinta-filppula at iso.org
>> Subject: Re: Submission draft-goodwin-iso-urn-00.txt -- application
>> for a formal NID
>>
>> The formating of the draft is bad. Please reformat and resubmit (The
>> lines are too long).
>>
>> Thank you.
>>
>>
>>> Please find attached a renamed file for application for a formal NID.
>>>
>>> If there is anything else that needs to be done to assure submission
>>> could you please let us know as soon as possible.
>>>
>>> With best wishes
>>>
>>> Joanna Goodwin
>>>
>>> -----Original Message-----
>>> From: ids at ietf.org [mailto:ids at ietf.org]
>>> Sent: 2006-03-27 18:37
>>> To: goodwin at iso.org
>>> Cc: mckinley at iso.org; 'SC'; 'Holger Apel'; rinta-filppula at iso.org
>>> Subject: RE: Request for status of submission draft-iso-urn-00.txt
>>>
>>> Please read below, it says about the file name. Correct and resubmit.
>>> Thank you.
>>>
>>> 7. Naming and Submitting
>>> Internet-Draft filenames have four parts, separated with hyphens and
>>> which may themselves contain hyphens:
>>>
>>> All Internet-Draft filenames begin with "draft"
>>> Document source:
>>> Individual
>>> The name of the submitter (one of the authors). This can be a
>>> surname, a given name, or an email address used by an author, as
>>> specified in the Authors' Addresses section of the draft.
>>>
>>>
>>>> I'm sorry but I'm not sure that I understand. Do you mean that the
>>>> current file name "draft-iso-urn-00.txt" is incorrect? If so, could
>>>> you tell me what file name we should use (we thought that we had
>>>> complied with the rules)?
>>>>
>>>> If not, please note that I submitted the file with this name on
>>>> 2006-02-09.
>>>> I have attached a copy of that mail as well as another copy of the
>>>> file.
>>>>
>>>> We are anxious to progress this submission and so any assistance
>>>> that you can provide would be greatly appreciated.
>>>>
>>>> With best wishes
>>>>
>>>> Joanna Goodwin
>>>>
>>>> -----Original Message-----
>>>> From: internet-drafts at ietf.org [mailto:internet-drafts at ietf.org]
>>>> Sent: 2006-03-23 20:56
>>>> To: goodwin at iso.org
>>>> Subject: RE: Request for status of submission draft-iso-urn-00.txt
>>>>
>>>> Please resubmit with corrected file name.
>>>>
>>>> Thank you.
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Goodwin [mailto:goodwin at iso.org]
>>>> Sent: 2006-03-21 18:56
>>>> To: 'ids at ietf.org'
>>>> Subject: RE: Request for status of submission draft-iso-urn-00.txt
>>>>
>>>>> Would it be possible to receive some information regarding the
>>>>> status of the submission draft-iso-urn-00.txt.
>>>>>
>>>>> With best wishes
>>>>>
>>>>> Jo Goodwin
>>>>>
>>>>> Manager, Production Services
>>>>> Standards Department
>>>>> International Organization for Standardization (ISO)
>>>>>
>>>>> -----Original Message-----
>>>>> From: Goodwin [mailto:goodwin at iso.org]
>>>>> Sent: 2006-03-10 16:34
>>>>> To: 'ids at ietf.org'
>>>>> Subject: Request for status of submission draft-iso-urn-00.txt
>>>>>
>>>>> Thanks very much for the reply. I realize that you must have many
>>>>> documents
>>>>> -- sorry -- that is why I had replied to a previous mail to which
>>>>> the draft was attached. Now I know the system I'll make sure I put
>>>>> the file name in the subject line.
>>>>>
>>>>> Looking forwards to hearing from you
>>>>>
>>>>> Best wishes
>>>>>
>>>>> Jo Goodwin
>>>>>
>>>>> -----Original Message-----
>>>>> From: ids at ietf.org [mailto:ids at ietf.org]
>>>>> Sent: 2006-03-10 15:55
>>>>> To: goodwin at iso.org
>>>>> Subject: RE: Application for a formal NID
>>>>>
>>>>> Hi Jo,
>>>>>
>>>>> Let me explain you a little bit a process of draft posting. We
>>>>> usually receive hundreds of drafts (before the meeting the number
>>>>> is close to thousand). We post them in a timely manner and in
>>>>> order of
>>> receiving.
>>>>>
>>>>> I would of course inform you about the status of your draft if I
>>>>> have the file name. Please in the future when you request posting
>>>>> or status always in the Subject line give us the file name of the
> draft.
>>>>> This will help us to more quickly respond you.
>>>>>
>>>>> Thank you.
>>>>>
>>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Goodwin [mailto:goodwin at iso.org]
>>>> Sent: 2006-03-07 12:15
>>>> To: 'internet-drafts at ietf.org'; 'urn-nid at apps.ietf.org'
>>>> Subject: RE: Application for a formal NID
>>>>
>>>>>> Could I please enquire as to the status of this submission.
>>>>>>
>>>>>> With best wishes
>>>>>>
>>>>>> Jo Goodwin
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Goodwin [mailto:goodwin at iso.org]
>>>>>> Sent: 2006-02-09 14:34
>>>>>> To: 'internet-drafts at ietf.org'
>>>>>> Subject: RE: Application for a formal NID
>>>>>>
>>>>>> As far as I understand your rules, I have altered the file name
>>>>>> accordingly.
>>>>>> Please find the renamed file attached.
>>>>>>
>>>>>> With best regards
>>>>>>
>>>>>> Jo Goodwin
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: internet-drafts at ietf.org [mailto:internet-drafts at ietf.org]
>>>>>> Sent: 2006-02-08 22:40
>>>>>> To: goodwin at iso.org
>>>>>> Subject: RE: Application for a formal NID
>>>>>>
>>>>>> Please make sure that the draft-rfc-urn-iso-12 file name is correct.
>>>>>> And then resubmit.
>>>>>>
>>>>>> Thank you.
>>>>>>
>>>>>>
>>>>>>> Dear Secretariat
>>>>>>>
>>>>>>> I have carried out all the modifications listed and have updated
>>>>>>> the date and version number of the draft.
>>>>>>>
>>>>>>> Please find the revised file attached. If I need to do anything
>>>>>>> more in order for this draft to be accepted I'd be grateful if
>>>>>>> you would let me know.
>>>>>>>
>>>>>>> Thanks again for your help.
>>>>>>>
>>>>>>> Best regards
>>>>>>>
>>>>>>> Jo Goodwin
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: internet-drafts at ietf.org [mailto:internet-drafts at ietf.org]
>>>>>>> Sent: 2006-02-02 20:05
>>>>>>> To: goodwin at iso.org
>>>>>>> Subject: RE: Application for a formal NID
>>>>>>>
>>>>>>> The Secretariat CANNOT process your Internet-Draft submission
>>>>>>> due to following reason(s):
>>>>>>>
>>>>>>> * All Internet-Drafts must have on the first page an
>>>>>>> intellectual property rights (IPR) statement that says:
>>>>>>>
>>>>>>> By submitting this Internet-Draft, each author represents that
>>>>>>> any applicable patent or other IPR claims of which he or she is
>>>>>>> aware have been or will be disclosed, and any of which he or she
>>>>>>> becomes aware will be disclosed, in accordance with Section 6 of
>>>>>>> BCP
> 79.
>>>>>>>
>>>>>>> If you are using xml2rfc, this can be accomplished by updating
>>>>>>> the 'ipr'
>>>>>>> attribute in the 'rfc' element to refer to 3978. See
>>>>>>> http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html#
>>>>>>> i
>>>>>>> p
>>>>>>> r
>>>>>>> for more information.
>>>>>>>
>>>>>>> * All Internet-Drafts must include the following statement:
>>>>>>>
>>>>>>> Copyright (C) The Internet Society (2006).
>>>>>>>
>>>>>>>
>>>>>>> * All Internet-Drafts must include the following statement:
>>>>>>>
>>>>>>> This document is subject to the rights, licenses and
>>>>>>> restrictions contained in BCP 78, and except as set forth
>>>>>>> therein, the authors retain all their rights.
>>>>>>>
>>>>>>>
>>>>>>> * All Internet-Drafts must include the following statement:
>>>>>>>
>>>>>>> This document and the information contained herein are provided
>>>>>>> on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
>>>>>>> REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
>>>>>>> THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
>>>>>>> EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY
>>>>>>> THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
>>>>>>> RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
>>>>>>> FOR A PARTICULAR
>>> PURPOSE.
>>>>>>>
>>>>>>>
>>>>>>> * All Internet-Drafts must contain the full filename (beginning
>>>>>>> with
>>>>>>> draft-
>>>>>>> and including the version number) in the text of the document.
>>>>>>>
>>>>>>>
>>>>>>> * All Internet-Drafts must include the following statements:
>>>>>>>
>>>>>>> Internet-Drafts are working documents of the Internet
>>>>>>> Engineering Task Force (IETF), its areas, and its working
>>>>>>> groups. Note that other groups may also distribute working
>>>>>>> documents as Internet-Drafts.
>>>>>>> Internet-Drafts are draft documents valid for a maximum of six
>>>>>>> months and may be updated, replaced, or obsoleted by other
>>>>>>> documents at any time. It is inappropriate to use
>>>>>>> Internet-Drafts as reference material or to cite them other than
>>>>>>> as "work in progress."
>>>>>>>
>>>>>>> The list of current Internet-Drafts can be accessed at
>>>>>>> http://www.ietf.org/1id-abstracts.html
>>>>>>>
>>>>>>> The list of Internet-Draft Shadow Directories can be accessed at
>>>>>>> http://www.ietf.org/shadow.html
>>>>>>>
>>>>>>>
>>>>>>> * All Internet-Drafts must have an Abstract section.
>>>>>>>
>>>>>>> * All Internet-Drafts should contain a section giving the
>>>>>>> name(s) and contact information for the authors.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Apologies for the silence - I have been sick for the last few
>>>>>>>> days.
>>>>>>>>
>>>>>>>> Please find attached the document as a txt as requested.
>>>>>>>>
>>>>>>>> Thanks again for your help. Best regards
>>>>>>>>
>>>>>>>> Jo Goodwin
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: internet-drafts at ietf.org
>>>>>>>> [mailto:internet-drafts at ietf.org]
>>>>>>>> Sent: 2006-01-27 20:20
>>>>>>>> To: goodwin at iso.org
>>>>>>>> Subject: RE: Application for a formal NID
>>>>>>>>
>>>>>>>> You should send it in a plan TXT file. Please resubmit.
>>>>>>>>
>>>>>>>> Thank you.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Hello Dinara
>>>>>>>>>
>>>>>>>>> Thanks very much for the offer -- I really appreciate it. For
>>>>>>>>> your information, I did check the draft (even before I sent it
>>>>>>>>> the last
>>>>>>>>> time) against the I-D checklist that Leslie Daigle kindly
>>>>>>>>> pointed me towards and thought that the draft complied in all
>>>>>>>>> respects except that the Contents was not ragged right (but it
>>>>>>>>> was that way in the example file that I had been given so
>>>>>>>>> decided that it was probably ok), and I wasn't sure that the
>>>>>>>>> draft complied with the rule "It must not contain boilerplate
>>>>>>>>> that prohibits publication as an
>>>>> RFC"
>>>>>>>>> (but since I didn't/don't know what such boilerplate might be
>>>>>>>>> I cannot judge whether it does or does not comply with this rule).
>>>>>>>>>
>>>>>>>>> I have also looked at the Guidelines, but not being familiar
>>>>>>>>> with the IETF terminology I'm no longer even sure whether I'm
>>>>>>>>> submitting an RFC or an Internet draft -- I thought I was
>>>>>>>>> submitting an RFC but maybe I'm
>>>>>>>> wrong?
>>>>>>>>> So
>>>>>>>>> I really appreciate any help that you can provide me.
>>>>>>>>>
>>>>>>>>> I have attached the draft, and look forwards to receiving your
>>>>>>>>> reply.
>>>>>>>>>
>>>>>>>>> Best wishes
>>>>>>>>>
>>>>>>>>> Jo Goodwin
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: internet-drafts at ietf.org
>>>>>>>>> [mailto:internet-drafts at ietf.org]
>>>>>>>>> Sent: 2006-01-25 21:26
>>>>>>>>> To: goodwin at iso.org
>>>>>>>>> Subject: RE: Application for a formal NID
>>>>>>>>>
>>>>>>>>> Hello Jo,
>>>>>>>>>
>>>>>>>>> I would suggest you to submit your draft. As we receive it, we
>>>>>>>>> will check it for correctness. If everthing is okey, we post
>>>>>>>>> it
>>>>>>>>> --- if not, we will send you a message telling what and where
>>>>>>>>> you should add. I think this is the better solution for the
>> question.
>>>>>>>>>
>>>>>>>>> Thank you.
>>>>>>>>>
>>>>>>>>> Dinara Suleymanova
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Thanks for the info. As you can see I have no experience in
>>>>>>>>>> the submission of such documents, but am willing to learn.
>>>>>>>>>>
>>>>>>>>>> I have had a quick look at the document you gave a link to
>>>>>>>>>> below and have noticed that at least a certain number of the
>>>>>>>>>> things mentioned appear to be related to boilerplate texts. I
>>>>>>>>>> searched the guidelines to see whether there was a mention of
>>>>>>>>>> a template but could find no mention. Would it be possible to
>>>>>>>>>> provide me with a link to a template or alternatively to
>>>>>>>>>> provide me with an example of what you would consider to be a
>>>>>>>>>> good
>> draft?
>>>>>>>>>>
>>>>>>>>>> Thanks in advance
>>>>>>>>>>
>>>>>>>>>> Jo Goodwin
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: internet-drafts at ietf.org
>>>>>>>>>> [mailto:internet-drafts at ietf.org]
>>>>>>>>>> Sent: 2006-01-24 19:49
>>>>>>>>>> To: goodwin at iso.org
>>>>>>>>>> Cc: 'Leslie Daigle'; urn-nid at apps.ietf.org; clivio at iso.org;
>>>>>>>>>> 'Apel Holger'; 'Rinta-Filppula Pasi'; mckinley at iso.org
>>>>>>>>>> Subject: RE: Application for a formal NID
>>>>>>>>>>
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> Please find here the link which weill help you to properly
>>>>>>>>>> compose a draft.
>>>>>>>>>> As soon as you have all necessary statements in the drafts,
>>>>>>>>>> etc, please resubmit.
>>>>>>>>>>
>>>>>>>>>> http://www.ietf.org/ietf/1id-guidelines.html
>>>>>>>>>>
>>>>>>>>>> Thank you.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> The revised version is now ready and is attached. Thank you
>>>>>>>>>>> for your indulgence.
>>>>>>>>>>>
>>>>>>>>>>> Please do not hesitate to let me know if there's anything
>>>>>>>>>>> else that is required on my/our part.
>>>>>>>>>>>
>>>>>>>>>>> With best wishes
>>>>>>>>>>>
>>>>>>>>>>> Joanna Goodwin
>>>>>>>>>>> Manager, Production Services Standards Department
>>>>>>>>>>> International Organization for Standardization (ISO)
>>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Leslie Daigle [mailto:leslie at thinkingcat.com]
>>>>>>>>>>> Sent: 2006-01-19 18:42
>>>>>>>>>>> To: goodwin at iso.org
>>>>>>>>>>> Cc: urn-nid at apps.ietf.org; clivio at iso.org; 'Apel Holger';
>>>>>>>>>>> 'Rinta-Filppula Pasi'; mckinley at iso.org
>>>>>>>>>>> Subject: Re: Application for a formal NID
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Howdy,
>>>>>>>>>>>
>>>>>>>>>>> I look forward to the revised version.
>>>>>>>>>>>
>>>>>>>>>>> RFC3406 does actually stipulate the requirement:
>>>>>>>>>>>
>>>>>>>>>>> It's implicit here:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thus, the Formal NID application is made via publication
>>>>>>>>>>>> of an RFC
>>>>>>>>>>>> through standard IETF processes.
>>>>>>>>>>>
>>>>>>>>>>> (standard IETF processes begin with I-D publication) and
>>>>>>>>>>> spelled out in the detailed appendix:
>>>>>>>>>>>
>>>>>>>>>>>> 2. Send the Internet-Draft to the I-D editor, and send
>>>>>>>>>>>> a copy to
>>>>>>>>>>>> urn-nid at apps.ietf.org for technical review.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> If/when RFC3406 gets revised, I can see making that much
>>>>>>>>>>> more explicit upfront, particularly for people who aren't as
>>>>>>>>>>> immediately involved in the IETF work as some.
>>>>>>>>>>>
>>>>>>>>>>> Leslie.
>>>>>>>>>>>
>>>>>>>>>>> Goodwin wrote:
>>>>>>>>>>>> Thanks for your mail. I had attached the draft to the
>>>>>>>>>>>> e-mail that I sent.
>>>>>>>>>>>> Sorry about not putting it in the IETF Internet-Draft
>>>>>>>>>>>> repository
>>>>>>>>>>>> -- can't see that RFC 3406 mentions that it is necessary to
>>>>>>>>>>>> do this.
>>>>>>>>>>>> Is this rule given in another document that I should have
>>>>>>>>>>>> read?
>>>>>>>>>>>>
>>>>>>>>>>>> Since submitting this draft in December, I have received a
>>>>>>>>>>>> request from one of our TCs to alter the draft slightly.
>>>>>>>>>>>> Accordingly I will submit a slightly revised draft next week.
>>>>>>>>>>>>
>>>>>>>>>>>> Please accept my apologies for any inconvenience caused.
>>>>>>>>>>>>
>>>>>>>>>>>> With best wishes
>>>>>>>>>>>>
>>>>>>>>>>>> Joanna Goodwin
>>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: Leslie Daigle [mailto:leslie at thinkingcat.com]
>>>>>>>>>>>> Sent: 2006-01-10 19:08
>>>>>>>>>>>> To: goodwin at iso.org
>>>>>>>>>>>> Cc: urn-nid at apps.ietf.org; clivio at iso.org; 'Apel Holger';
>>>>>>>>>>>> 'Rinta-Filppula Pasi'; mckinley at iso.org
>>>>>>>>>>>> Subject: Re: Application for a formal NID
>>>>>>>>>>>>
>>>>>>>>>>>> As noted by the list moderator, a number of messages were
>>>>>>>>>>>> held up in the moderation queue until January 6, 2006 -- so
>>>>>>>>>>>> we did not see your message until then.
>>>>>>>>>>>>
>>>>>>>>>>>> For this request -- I am unable to find the document in the
>>>>>>>>>>>> IETF Internet-Draft repository. Could you please provide
>>>>>>>>>>>> the exact pointer, or make sure to submit the document
>>>>>>>>>>>> there if you have not already
>>>>>>>>>>> done so[*].
>>>>>>>>>>>>
>>>>>>>>>>>> Best regards,
>>>>>>>>>>>> Leslie.
>>>>>>>>>>>>
>>>>>>>>>>>> [*] See http://www.ietf.org/ID.html
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Goodwin wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>Dear IETF org
>>>>>>>>>>>>>
>>>>>>>>>>>>>Please find attached an application for a formal NID from
>>>>>>>>>>>>>the International Organization for Standardization (ISO).
>>>>>>>>>>>>>Should you require any further information, please do not
>>>>>>>>>>>>>hesitate to contact us.
>>>>>>>>>>>>>In the meantime please accept our best wishes for the
>>>>>>>>>>>>>festive season.
>>>>>>>>>>>>>
>>>>>>>>>>>>>Best regards
>>>>>>>>>>>>>
>>>>>>>>>>>>>Joanna Goodwin
>>>>>>>>>>>>>Manager, Production Services Standards Department
>>>>>>>>>>>>>International Organization for Standardization (ISO)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Network Working Group J. Goodwin
Internet-Draft ISO
Expires: October 14, 2006 April 12, 2006
A Uniform Resource Name (URN) Namespace for the International
Organization for Standardization (ISO)
draft-goodwin-iso-urn-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 14, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes a Uniform Resource Name Namespace
Identification (URN NID) for the International Organization for
Standardization (ISO). This URN NID is intended for use for the
identification of persistent resources published by the ISO standards
body (including documents, document metadata, extracted resources
such as standard schemata and standard value sets, and other
resources).
Table of Contents
1. Introduction
2. Specification Template
2.1. Namespace ID
2.2. Registration Information
2.3. Declared registrant of the namespace
2.4. Declaration of structure
2.5. Relevant ancillary documentation
2.6. Identifier uniqueness considerations
2.7. Identifier persistence considerations
2.8. Process for identifier resolution
2.9. Rules for lexical equivalence
2.10. Conformance with URN Syntax
2.11. Validation mechanism
2.12. Scope
3. Namespace Considerations
3.1. Requirements
3.2. Alternative naming schemes
4. Community Considerations
5. IANA Considerations
6. Security Considerations
7. References
7.1. Normative References
7.2. Informative References
Author's Address
Intellectual Property and Copyright Statements
1. Introduction
The International Organization for Standardization (ISO) was created
by international agreement in 1947. ISO is a network of the national
standards institutes of many countries, on the basis of one member
per country, with a Central Secretariat in Geneva, Switzerland, that
coordinates the system. ISO acts as a bridging organization in which
a consensus can be reached on solutions that meet both the
requirements of business and the broader needs of society, such as
the needs of stakeholder groups like consumers and users.
(Further information is provided at
http://www.iso.org/iso/en/aboutiso/introduction/index.html.)
The core mission of ISO is to develop technical standards
constituting technical agreements which provide the framework for
compatible technology worldwide. ISO standards contribute to making
the development, manufacturing and supply of products and services
more efficient, safer and cleaner. They make trade between countries
easier and fairer.
Every participating ISO member institute (full members) has the right
to take part in the development of any standard which it judges to be
important to its country's economy. No matter what the size or
strength of that economy, each participating member in ISO has one
vote. ISO's activities are thus carried out in a democratic
framework where each country is on an equal footing to influence the
direction of ISO's work at the strategic level, as well as the
technical content of its individual standards. Although ISO
standards are voluntary, the fact that they are developed in response
to market demand, and are based on consensus among the interested
parties, ensures widespread applicability of the standards.
Consensus, like technology, evolves and ISO takes account both of
evolving technology and of evolving interests by requiring a review
of its standards at least every five years to decide whether they
should be maintained, updated or withdrawn.
ISO publishes International Standards and other technical
specifications that are cited in the definitions of required or
expected practices in many industries in many nations. These
specifications contain dictionaries of standard terms, catalogues of
reference values, definitions of formal languages, formal schemata
for information capture and exchange, specifications for standard
practices, and other information resources of general use to
international trade and industry. ISO wishes to create and manage
globally unique, persistent, location-independent identifiers for
these resources.
This specification defines the syntax for URNs that identify
documents developed by the International Organization for
Standardization (ISO) in accordance with the standards development
procedures defined in the ISO/IEC Directives, Part 1 [ISODIR-1] and
the ISO supplement [ISODIR-S] and processed by the ISO Central
Secretariat. The syntax extends to identify document metadata and
resources related to these documents or otherwise associated with
them. It does not extend to products derived from these documents
and published by ISO (e.g. handbooks, compendia) or documents at or
below the Technical Committee level. Revisions of this specification
may define syntax for URNs in this namespace that identify other ISO
objects, when the ISO community defines a requirement for such
identifiers.
2. Specification Template
2.1. Namespace ID
"iso"
2.2. Registration Information
Version 1.5
Date: 2006-04-11
2.3. Declared registrant of the namespace
J. Goodwin
ISO Central Secretariat
International Organization for Standardization (ISO)
Case Postale 56
CH-1211 Geneva 20
Switzerland
E-mail: goodwin at iso.org
2.4. Declaration of structure
The Namespace Specific Strings (NSS) of all URNs assigned by ISO will
conform to the syntax defined in section 2.2 of [RFC2141].
The NSS has the following ABNF [RFC2234] specification:
NSS = std-nss
All URNs conforming to this specification begin the NSS with the
prefix "std:", to denote the restriction to documents developed by
the ISO standards development procedures as defined in the ISO/IEC
Directives, Part 1 [ISODIR-1] and the ISO Supplement [ISODIR-S].
Prefixes that identify ISO objects of other kinds may be defined
in future revisions of this specification.
std-nss = "std:" docidentifier *supplements *docelement
[additions]
The prefix "std:" distinguishes an "std-nss". An std-nss
identifies the ISO document that is designated by the
"docidentifier", as extended or modified by any identified
"supplements". (An std-nss that identifies all parts of a
multipart ISO document is a special case as described under the
element "partnumber".) If the std-nss contains an "additions"
element, the NSS identifies a resource extracted from the ISO
document or otherwise associated with it (see below).
docidentifier = originator [":" type] ":" docnumber [":" partnumber]
([":" status ":" edition] / [":" edition])
[":" docversion] [":" language]
"docidentifier" provides the complete identification of an ISO
document. Each of its component elements is described below.
originator = "iso" / "iso-iec" / "iso-cie" / "iso-astm" /
"iso-ieee" / "iec"
"originator" the organization (usually an international body) from
which a document emanates.
Current values:
iso = International Organization for Standardization
iec = International Electrotechnical Commission (IEC), or
Commission internationale electrotechnique (CIE)
iso-iec = jointly developed by ISO and IEC
iso-cie = jointly developed by ISO and the Commission
internationale d'eclairage (CEI)
iso-astm = jointly developed by ISO and the American Society for
Testing and Materials International (ASTM)
iso-ieee = jointly developed by ISO and the Institute for
Electrical and Electronics Engineers (IEEE)
Revisions of this specification may define additional values.
type = "data" / "guide" / "isp" / "iwa" /
"pas" / "r" / "tr" / "ts" / "tta"
"type" designates the ISO deliverable type. If the "type" element
is not present, the classification is "international standard".
Other current values:
data = Data (document type no longer published)
guide = Guide
isp = International Standardized Profile
iwa = International Workshop Agreement
pas = Publicly Available Specification
r = Recommendation (document type no longer published)
tr = Technical Report
ts = Technical Specification
tta = Technology Trends Assessment
docnumber = DIGITS
"docnumber" is the reference number assigned to the document by
ISO and/or IEC. An ISO document may comprise a single document,
or two or more separate parts each of which is identified by
"partnumber".
partnumber = "-" +( DIGIT / ALPHA / "-" )
"partnumber" is the reference number that identifies a part of a
multipart standard.
Where it is required to refer to a multipart ISO document in its
entirety, this can be designated by omitting the "partnumber"
element. However, this precludes the possibility of using any
further elements except "additions".
_NOTE_ This option has been included to align with the provision
in the ISO/IEC Directives, Part 2, 2004 [ISODIR-2] subclause 6.2.2
of making an undated reference to all parts of an ISO document.
It is only permissible to use this option where the URN is
referring to a multipart ISO document in its entirety. Since the
use of this option precludes the designation of the elements
"status" and "edition", it is implicit that the URN needs to
remain valid irrespective of any future changes to the multipart
document (see the rules for undated references given in the ISO/
IEC Directives, Part 2, 2004 [ISODIR-2] subclause 6.6.7.5.2).
This shall be taken into consideration in the use (and
maintenance) of any URN specification employing this option.
_NOTE_ In the case where the multipart document comprises
different types of ISO deliverable, the "type" of the core part
(usually part 1) applies. See the example "Reference to a
resource related to all parts of a multipart document".
Except for the case where it is required to refer to a multipart
document in its entirety, this element is required if the
identified resource is a part of an ISO document. Otherwise, this
element is not used.
status = ( "draft" / "cancelled" ) / stage
"status" indicates the publication status of the document. When
the "status" element is not present, the NSS refers to a published
document. Other values:
draft = document that has not yet been accepted for
publication by international ballot
cancelled = document that has been deleted or withdrawn
stage = "stage-" stagecode ["." iteration]
"stage" indicates the stage code and iteration of the document.
stagecode = DIGIT DIGIT "." DIGIT DIGIT
"stagecode" is the harmonized stage code in accordance with ISO
Guide 69:1999, "Harmonized Stage Code system (Edition 2) --
Principles and guidelines for use" [ISOGUIDE69].
iteration = "v" DIGIT
"iteration" is a sequential number which refers to a specific
iteration of the project's lifecycle through the designated stage
If no "iteration" is specified the reference is to the highest
iteration available for the specified stagecode.
_NOTE_ In the ISO Central Secretariat project management database
the "iteration" is referred to as the "project version".
edition = "ed-" DIGIT
"edition" designates a specific edition of the document. (The
DIGIT is the (sequential) edition number.) If no "edition" is
specified, the NSS refers to the latest edition.
docversion = "v" (simpleversion / isoversion)
simpleversion = DIGIT
"docversion" designates the version number of a document's
"edition". It is altered by correction (corrected version;
Technical Corrigendum) or amendment (Amendment; Addendum) and is
distinct from a revision, which changes the edition number.
In the "simpleversion", the first version published is "1", and
each subsequent correction or amendment increases the version
number by 1.
If no "docversion" is specified, the reference is to the highest
version number available for the denoted "edition".
Current values:
1 - first version published
2 - corrected version published
isoversion = baseversion *includedsuppl
baseversion = DIGIT
includedsuppl = "-" suppltype supplnumber [ "." supplversion ]
An "isoversion" can be linked to a simpleversion by defining an
existing simpleversion as baseversion and listing all the
"supplements" (corrections and amendments) incorporated into that
version.
Examples for the "isoversion" (internal ISO version) scheme:
1 = first version of standard
1-amd1.v1 = first version of standard incorporating first
version of Amendment 1
1-amd1.v1-amd2.v1 = first version of standard incorporating
first version of Amendment 1 and first version of Amendment 2
1-amd1.v2-amd2.v1-amd3 = first version of standard
incorporating corrected version of Amendment 1, first version
of Amendment 2, and highest version of Amendment 3
1-cor3 = first version of standard incorporating highest
version of Technical Corrigendum 3
1-amd1-cor3 = first version of standard incorporating highest
version of Amendment 1 and highest version of Technical
Corrigendum 3
language = monolingual / bilingual / trilingual
monolingual = "en" / "fr" / "ru" / "es" / "ar"
bilingual = "en-fr" / "en-ru" / "fr-ru"
trilingual = "en-fr-ru"
"language" designates the official ISO language(s), or the
language of a certified translation, in which the document
(object) is processed and published by ISO (excluding languages
which constitute only specific elements of the content). The
value is one or more alpha-2 codes, each of which designates a
language, as specified in ISO 639-1 [ISO639-1]. If no language
element is specified, "en" is assumed.
supplements = ":" suppltype ":" supplnumber
[":" supplversion ] [":" language ]
suppltype = "amd" / "cor" / "add"
supplnumber = DIGIT
supplversion = "v" DIGIT
"supplements" designate technical alterations of or additions to
an ISO standard that do not result in a new "edition" or
"version". Supplements are of three types, designated by
"suppltype":
amd = Amendment -- a document that alters and/or adds to
previously agreed technical provisions in an existing ISO
document; an amendment is subject to acceptance by ballot in
accordance with the ISO/IEC Directives, Part 1, 2004
[ISODIR-1] subclause 2.10.3
cor = Technical Corrigendum -- a document that corrects a
technical error or ambiguity, or updates the ISO document in
such a way that the modification has no effect on the
technical normative elements; a Technical Corrigendum is not
balloted -- see the ISO/IEC Directives, Part 1, 2004
[ISODIR-1] subclause 2.10.2
add = Addendum -- (document type no longer published) Addenda were
documents that changed (by correction, addition or deletion)
the technical requirements of an ISO document; an addendum
was subject to acceptance by ballot in accordance with the
ISO/IEC Directives, Part 1. (Addenda are included in this
RFC because some of them are still valid.)
Supplements are numbered consecutively per ISO document, and
within each type.
"supplnumber" identifies the number of the supplement.
"supplversion" designates the version of a published supplement.
At present only two versions are used in practice: when a
supplement is published it is a version 1. If that supplement is
subsequently corrected by issuing a corrected version, as
designated by the term "Corrected" on the cover page together with
a date, the corrected version is version 2.
The language of a supplement can be different from that of the
document. For example, a supplement may apply to only one of the
languages of a bilingual document. For such cases, the language
of a supplement can be identified using the "language" element
defined above. The interpretation is the same, except that it
applies only to the supplement.
docelement = clause / term
clause = ":clause:" clauseno / clauserange
*( "," clauseno / clauserange )
clauseno = ( ALPHA / DIGITS ) *( "." DIGITS )
clauserange = clauseno "-" clauseno
term = ":term:" termno / termrange
*( "," termno / termrange)
termno = ( ALPHA / DIGITS ) *( "." DIGITS )
termrange = termno "-" termno
"docelement" identifies one or more numbered subdivisions of a
document. Types of numbered subdivision are specified in the ISO/
IEC Directives, Part 2 [ISODIR-2]. This RFC currently specifies
forms for reference to terms and clauses only. Revisions of this
specification may define additional values.
"clause" represents the selection of one or more clauses or
subclauses of the specification. The form "clauseno HYPHEN
clauseno" designates a range of (sub)clauses and the form
"clauseno COMMA clauseno" a list. A list can contain ranges.
"clauseno" designates one clause or subclause in a specification.
When the first character of a "clauseno" is a digit, the reference
is to the clause designated by that digit string, and to the
subclause designated by any additional digit strings separated by
periods. When the first character of a "clauseno" is
alphabetical, the reference is to the corresponding Annex, and to
the (sub)clauses designated by additional digit strings.
"term" represents the selection of one or more consecutive terms
of the specification. The form "termno HYPHEN termno" designates
a range of terms and the form "termno COMMA termno" a list. A
list can contain ranges.
"termno" designates one term in a specification. When the first
character of a "termno" is a digit, the reference is to the term
designated by that digit string and by any additional digit
strings separated by periods. When the first character of a
"termno" is alphabetical, the reference is to the corresponding
Annex, and to the terms designated by additional digit strings.
additions = techdefined / isodefined
techdefined = ":tech" *techelement
techelement = ; unspecified
isodefined = ; unspecified
"additions" are additional elements of the NSS intended to
identify a representation of an ISO document, an extract from an
ISO document, or some related information set, as a resource in
its own right.
"techdefined" represents an associated or embedded resource
defined by the committee that develops or maintains the identified
document. All such "additions" begin with the keyword "tech", but
the further syntax is defined by the committee.
"isodefined" represents associated or embedded resources defined
by the ISO Central Secretariat. The definition of "additions"
beginning with any symbol other than "tech" is reserved to the ISO
Central Secretariat.
The syntax of these additions is not specified in this RFC.
Specific syntax for these additions will be specified as needed by
the ISO Central Secretariat, or by the individual Committee that
has the responsibility for developing or maintaining the
identified document. (See further discussion under Process for
Identifier Resolution below.)
DIGITS = DIGIT *DIGIT
DIGIT = "0" / "1" / "2" / "3" / "4" /
"5" / "6" / "7" / "8" / "9"
ALPHA = "A" / "B" / "C" / "D" / "E" / "F" / "G" /
"H" / "I" / "J" / "K" / "L" / "M" / "N" /
"O" / "P" / "Q" / "R" / "S" / "T" / "U" /
"V" / "W" / "X" / "Y" / "Z"
Basics of the ABNF notation used :
" " literals (terminal character strings);
terms not in quotes are non-terminals
/ alternatives
[] indicates an optional rule
() indicates a group of rules, used as a single alternative or as a
single repeating group
* indicates that the following term or group can repeat 0 or more
times
+ indicates that the following term or group can repeat 1 or more
times
; comment
Examples
o Language handling:
urn:iso:std:iso:9999:-1:ed-1:en
refers to the 1st edition of ISO 9999-1, in English
urn:iso:std:iso:9999:-1:ed-1:en-fr
refers to the 1st edition of ISO 9999-1, in English/French
(bilingual document)
o Originators/document type:
urn:iso:std:iso-iec:tr:9999:-1:ed-1:en
refers to the 1st edition of ISO/IEC TR 9999-1, in English
o Status:
urn:iso:std:iso-iec:9075:-3:cancelled:ed-2:en
urn:iso:std:iso-iec:9075:-3:stage-95.99:ed-2:en
both refer to the cancelled 2nd edition of ISO/IEC 9075-3, in
English
urn:iso:std:iso-iec:9075:-3:draft:ed-4:en
urn:iso:std:iso-iec:9075:-3:stage-30.60:ed-4:en
both refer to the draft 4th edition of ISO/IEC 9075-3, in English
urn:iso:std:iso:128:-20:en
urn:iso:std:iso:128:-20:stage-90.20:ed-1:en
both refer to the published (90.20 = under 2nd periodic review)
1st edition of ISO 128-20, in English
urn:iso:std:iso:128:-71:cancelled:ed-1:en
urn:iso:std:iso:128:-71:stage-30.98.v2:ed-1:en
both refer to the cancelled (30.98 = project deleted) 1st edition
of ISO 128-71, in English; the second example refers specifically
to the 2nd iteration (projectversion) at stage 30
o Non-numeric part number:
urn:iso:std:iso:9999:-A02:ed-1:en
refers to the 1st edition of ISO 9999-A02, in English
o Reference to a resource related to all parts of a multipart
document:
urn:iso:std:iso:20022:tech:xsd:camt.001.001.01
refers to a "techdefined" resource (i.e. a resource defined by the
committee that develops or maintains the identified document)
associated with ISO 20022 in its entirety; in this example the
techdefined part comprises ":xsd:camt.001.001.01"
_NOTE_ At the time of drafting of this schema, ISO 20022 comprises
5 parts: parts 1 and 2 are International Standards; parts 3 to 5
are Technical Specifications. Therefore the "doctype" standard is
used in the URN.
o Docversion handling:
urn:iso:std:iso:9999:-1:ed-1:v2:en
refers to the corrected English version of 1st edition of ISO
9999-1
urn:iso:std:iso:9999:-1:ed-1:v1-amd1:en
refers to the version comprising 1st edition of ISO 9999-1,
incorporating the latest version of Amendment 1, in English
urn:iso:std:iso:9999:-1:ed-1:v1:en-fr:amd:1:v2:en
refers to the 2nd version of Amendment 1, in English, which amends
the 1st version of edition 1 of ISO 9999-1, in English/French
(bilingual document)
urn:iso:std:iso:9999:-1:ed-1:v1-amd1.v1:en-fr:amd:2:v2:en
(isoversion scheme)
refers to the corrected version of Amendment 2, in English, which
amends the document comprising the 1st version of edition 1 of ISO
9999-1 incorporating the 1st version of Amendment 1, in English/
French (bilingual document)
urn:iso:std:iso:5817:ed-2:v2:en:cor:1:en
refers to the 1st version of Technical Corrigendum 1, in English,
which amends the corrected version of edition 2 of ISO 5817, in
English
o Supplement handling:
urn:iso:std:iso:9999:-1:ed-2:en:amd:1
refers to Amendment 1 to 2nd edition of ISO 9999-1, in English
urn:iso:std:iso:9999:-1:ed-2:en:amd:1:v2
refers to corrected version of Amendment 1 to 2nd edition of ISO
9999-1, in English
urn:iso:std:iso:9999:1:ed-2:en-fr:amd:2:en
refers to Amendment 2 in English to 2nd edition of ISO 9999-1, in
English/French (bilingual document)
urn:iso:std:iso:9999:-1:ed-2:en:amd:1:cor:1
refers to Corrigendum 1 to Amendment 1 to 2nd edition of ISO
9999-1, in English
2.5. Relevant ancillary documentation
ISO/IEC Directives, Part 1 [ISODIR-1] and Part 2 [ISODIR-2], and ISO
supplement [ISODIR-S].
2.6. Identifier uniqueness considerations
Assignment of URNs for documents in the requested namespace will be
managed by the ISO Central Secretariat, which will ensure that the
assigned URNs are consistent with the ISO Directives for unique
identification of ISO documents.
Assignment of URNs for Technical Committee resources related to ISO
documents will be managed by the Technical Committees developing or
maintaining those documents. As indicated above, each such URN will
extend the URN for the containing document via "additions". The
responsibility of the Technical Committee will therefore be to ensure
the uniqueness of the techdefined "addition" that constitutes the
identifier for the resource within the document namespace, and thus
the uniqueness of the overall resource identifier within the
requested namespace.
2.7. Identifier persistence considerations
Assigned URNs will not be reused and will remain valid beyond the
lifecycle of the referenced resources. However, it should be noted
that although the URNs remain valid, the status of the referenced
resource may change.
2.8. Process for identifier resolution
Resolving document identifiers:
This schema has been developed with the intent that a URN
identifying an ISO document can be transformed to a valid http URI
by replacing the requested URN namespace prefix ("iso") and the
"std:" prefix with the domain name "standards.iso.org" and
replacing all occurrences of ":" within the identifier with "/".
(ISO is planning to develop a website implementation to support
these URIs.)
Examples:
urn:iso:std:iso:9999:-1:ed-1:en: corresponds to:
http://standards.iso.org/iso/9999/-1/ed-1/en/
urn:iso:std:iso-iec:tr:9999:-1:ed-1:en: corresponds to:
http://standards.iso.org/iso-iec/tr/9999/-1/ed-1/en/
urn:iso:std:iso:9999:-1:ed-2:en-fr:amd:2: corresponds to:
http://standards.iso.org/iso/9999/-1/ed-2/en-fr/amd/2/
Resolving identifiers for "addition" resources:
For URNs in the requested namespace that refer to additional
resources related to ISO documents, the ISO Central Secretariat
will specify the resolution procedure at the time it defines the
syntax for the corresponding "addition" to the NSS. In most
cases, those resources will be maintained on an ISO website, as
extensions to the HTTP URIs described above.
2.9. Rules for lexical equivalence
URNs are lexically equivalent if and only if they are lexically
identical.
The "case" of alphabetic characters in "part" elements is specified
to be "upper case", in order to avoid ambiguity with other elements
that may follow a docnumber, have similar representations, and begin
with "lower case" alphabetics.
2.10. Conformance with URN Syntax
No special considerations.
2.11. Validation mechanism
None specified.
2.12. Scope
Global.
3. Namespace Considerations
3.1. Requirements
The ISO specific requirements are as follows:
o globally unique, persistent identifiers
o location-independent identifiers
o human-interpretable identifiers
o a scheme applicable to paper documents as well as machine-readable
documents
o a scheme applicable to conceptual documents and explicit forms of
documents
o a scheme applicable to resources extracted from documents
o a scheme applicable to "metadata" associated with documents
o a scheme in which the identifier assignment is managed by the ISO
Central Secretariat.
Location-independence: Because the publication of ISO standards is a
complex arrangement involving multiple development organizations and
national standards institutes, a given ISO document may be available
in a number of forms from a number of sources. This makes it
important to have a document identifier that is global in scope,
widely and uniformly used, and independent of the text source used by
any given reference.
Human-interpretable: Many, perhaps most, references to documents
appear in text generated by human authors. It is important that an
author familiar with the scheme be able to generate a correct URN for
a document for which s/he has the ISO reference (or document
identifier). Conversely, it is important that a reader unfamiliar
with the scheme be able to identify the URN as a reference to an ISO
document, particularly an ISO standard, and also to recognize
identifiers for forms, languages, or metadata sets.
Paper documents: Older ISO standards that are commonly used as
industrial references exist only in paper form or in earlier machine-
readable forms that are not commonly used on the Internet. It is
important to have a document identifier scheme that extends to these
resources as well. (In fact, many of these have been converted to
Internet forms, and others are being converted, but it is important
that the identifier be independent of the form in which the document
can be obtained at any given time.)
Conceptual documents vs. representation forms: Because ISO documents
are regularly maintained and re-published in multiple forms, it is
important to have document identifiers that denote the conceptual
document, without regard to publication form. At the same time, it
is necessary for certain types of use to be able to refer to specific
editions, or specific publication forms (for example, editions in
different languages, or to PDF or HTML versions).
Document extracts: ISO standards may contain formal specifications in
machine-processable languages, or formal specifications that also
have representations in machine-processable languages. It is useful
to be able to extract these specifications in machine-processable
form as separate resources, and therefore it is necessary to give
these "extracted resources" global identifiers derived from the
document identifier using a consistent identification scheme.
Document metadata: Certain uses of documents and document text,
primarily bibiliographic, also extract information from the
documents, and that information, commonly called "metadata", is
organized in machine-readable forms conforming to other standards.
These metadata sets then become resources in their own right. It is
important to give them URN identifiers consistent with the document
identification scheme.
3.2. Alternative naming schemes
Before initiating this request, ISO attempted to find an existing or
currently proposed URN NID scheme that might be used instead of a
dedicated scheme. Two existing schemes were carefully considered,
because they clearly meet part of the requirements:
o The OID scheme, documented in [RFC3061]
o The PublicId scheme, documented in [RFC3151]
The OID scheme is derived from the joint ISO/ITU-T ASN.1 object-
identifier scheme specified in ISO/IEC 8824-1:2002 (original edition
1984, the RFC cites the 1988 CCITT edition of the encoding rules in
ISO/IEC 8825). This standard assigned to ISO the registry authority
for all identifiers in the { iso(1) } namespace, and therefore, ISO
controls the registry of all identifiers beginning "oid:1:". And in
fact, ISO has developed, and is using, an identification scheme under
ASN.1 that meets most of the above requirements. ISO could clearly
define a use of the OID scheme that would be adequate to meet all of
its technical objectives, although it would further complicate the
current ASN.1 scheme.
The original intent of ISO 8824 was to permit both a human-readable
form for the identifier, to maximize intuitive recognition, and an
encoding that minimized the number of bits needed to communicate an
OID value over a network. Regrettably, the encoding chosen in RFC
3061 is much closer to the minimal bits encoding than to the human-
readable one. The NSS for the OID scheme consists entirely of digits
and punctuation. For example, the ASN.1 identifier
{ iso(1) standard(0) 7852 part(2) edition(3) }
becomes: urn:oid:1:0:7852:2:3.
This is difficult for a human reader or author to interpret. It is
also easy to mistype, and the scheme contains no "check-digits",
which makes it difficult to validate, leading to the propagation of
URNS that are invalid or valid but erroneous. Finally, the all-
numeric form conveys no hint of the name of the responsible
organization and therefore no hint of any URL that might aid a human
reader in interpreting the reference. The OID scheme makes all of
the required identifiers technically possible and technically useable
by software, but for all practical purposes, the OID URNs are useful
only to software.
The PublicId scheme is derived from SGML (ISO 8879:1986 and ISO 9070:
1991) bibliographic catalogue forms. Narrowed to ISO publications,
it is adequate for the unique global persistent identification of
published documents, in both paper and machine-processable form.
Importantly, the PublicId scheme does not have a "conceptual
document" notion -- it identifies specific publications and editions.
"Weak identification" could be used to implement the conceptual
document concept, but the PublicId scheme does not document that
interpretation. And in any case, the PublicId scheme does not extend
to draft documents, which are often referenced in pilot
implementations, to separate forms of a document, or to resources
extracted from documents. It supports only those metadata elements
that are defined in SGML. The scheme could be extended to do most of
these, but the ISO-specific extensions would not in general extend to
the much broader base of documents identified by PublicIds. (Version
and edition management practices vary significantly across
publishers, depending on their milieu.) Further, ISO Central
Secretariat could not and should not control the registry of such
URNs.
ISO therefore concluded that the alternative schemes are not adequate
to meet the requirements of the ISO community.
Whilst requesting a new namespace for ISO documents and their
derivatives, ISO does not wish to discourage the use of these other
identifiers for ISO publications. The PublicId form, in particular,
is useful for referring to ISO publications in a larger bibliographic
information space.
4. Community Considerations
The ISO community is broad in two dimensions. In one dimension, its
documents are developed and used in a large variety of industries and
professions: natural sciences, manufacturing, construction,
transportation, information technology, social sciences, etc. In the
other dimension, it is a community of expert developers, standards
managers, publishers, professional users and consumers. And Internet
information technologies are a part of common professional practice
in all of these areas in both dimensions.
ISO standards are cited in business agreements, in professional
publications, in product descriptions, and in standards development
and publication activities. When these citations appear in
electronic form, the references must be unambiguous.
The information technology community is itself very active in the
development and use of standards, and many ISO publications are
developed by and for that community. When an Internet information
exchange uses a form specified in an ISO document, or a terminology
defined in an ISO document, it is often necessary to identify that
ISO specification in the envelope surrounding the exchange. That
identification should use a formal unambiguous identifier in a form
readily recognized by the receiving software, and possibly by the
ultimate human recipient of the information.
In order to facilitate the use of existing and emerging Internet
technologies for all of these purposes, URNs conforming to IETF RFC
2141 represent the most useful form of formal globally unambiguous
identifier. The use of a managed namespace for such identifiers,
following a consistent scheme for identifying ISO documents and their
derivatives would be of significant benefit to the entire ISO
community.
It would give professional users in many industries a standard
form for electronic reference to ISO standards in HTML, XML, PDF,
etc., documents.
It would give software developers a standard form for reference to
ISO standard protocols, schemata, languages, data sets, etc.
It would give standards developers a standard form for reference
to other ISO publications in various stages of development. And
it would give them a standard form for creating identifiers for
machine-readable information sets contained in, or derived from,
the specifications.
It would give standards managers and publishers a formal uniform
scheme for reference to specific publications, editions and
versions of ISO documents.
While the assignment of identifiers under this scheme is managed by
the ISO Central Secretariat, the processes by which the identified
objects arise and acquire such identifiers are the result of
agreements made by the member bodies. Every such project is
initiated by one member body and reviewed and voted on by the others.
Every accepted project is open to participation by any member body,
and in fact, participation by a certain minimum number (usually 5) of
member bodies is required for acceptance of most projects. In
general, the member bodies are open professional and industrial
organizations reflecting broad expertise and national interest.
It should be noted that ISO documents in draft state are not usually
made available outside the ISO standards development community.
Making them available to professionals outside of the process might
well mislead the recipients into premature adoption of practices that
are not yet completely specified or have not yet achieved consensus,
and therefore may well change.
It should also be noted that ISO documents are not, in general,
freely available over the Internet. Rather there are complex
agreements between ISO and its member institutes as to the rights to
the publications and the corresponding fees that may be charged for
paper or electronic copies of various editions. Some ISO documents
are freely available, and some are freely available in certain forms.
In general, derivatives of ISO documents (schemata, metadata sets,
etc.) are freely available over the Internet in the appropriate
machine-readable forms. A URL associated with a URN in the requested
namespace may therefore lead directly to a machine-readable copy of
the text of the document or derivative, or it may lead to a site that
can provide that text for a fee, or it may lead to a site that can
only sell a paper copy of the document. Bearing in mind that ISO is
a network of otherwise independent institutes, this behaviour is
simply a property of the ISO community.
Finally, it should be noted that, for many purposes, reference to the
ISO standard is what is required, and only the product engineer or
software tool builder actually needs access to the text. This
request is based on the need to standardize the form of reference,
not the means of access.
5. IANA Considerations
(responsibility of the IANA registry)
6. Security Considerations
The ISO URN Namespace ID shares the security considerations outlined
in [RFC3406], but has no other known security considerations.
7. References
7.1. Normative References
[ISODIR-1]
International Organization for Standardization,
"Procedures for the technical work", ISO/IEC
Directives Part 1, Edition 5, 2004.
[ISODIR-2]
International Organization for Standardization, "Rules for
the structure and drafting of International Standards",
ISO/IEC Directives Part 2, Edition 5, 2004.
[ISODIR-S]
International Organization for Standardization,
"Procedures specific to ISO", ISO/IEC
Directives Supplement.
[ISOGUIDE69]
International Organization for Standardization,
"Harmonized Stage Code system (Edition 2) - Principles and
guidelines for use.", ISO Guide 69:1999.
[ISO639-1]
International Organization for Standardization, "Codes for
the representation of names of languages - Part 1: Alpha-2
code", ISO 639-1:2002.
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
"Uniform Resource Names (URN) Namespace Definition
Mechanisms", BCP 66, RFC 3406, October 2002.
7.2. Informative References
[RFC3061] Mealling, M., "A URN Namespace of Object Identifiers",
RFC 3061, February 2001.
[RFC3151] Walsh, N., Cowan, J., and P. Grosso, "A URN Namespace for
Public Identifiers", RFC 3151, August 2001.
Author's Address
J. Goodwin
International Organization for Standardization
Case Postal 56
Geneva 20 1211
Switzerland
Email: goodwin at iso.org
URI: http://www.iso.org
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr at ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.