idnits 2.17.1 draft-hendrikx-wallis-urn-nzl-00.txt: -(360): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.5 on line 475. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 452. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 459. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 465. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 8) being 64 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 34 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 11, 2005) is 7013 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'UCS' on line 288 -- Looks like a reference, but probably isn't: 'STD63' on line 290 == Unused Reference: '1' is defined on line 402, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 406, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 411, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 415, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 418, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 422, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 425, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3406 (ref. '1') (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 2396 (ref. '2') (Obsoleted by RFC 3986) -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. '4') (Obsoleted by RFC 5226) Summary: 7 errors (**), 0 flaws (~~), 12 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft F. Hendrikx and C. Wallis 3 Expires: August 10, 2005 E-government Unit 4 State Services Commission 5 New Zealand Government 6 February 11, 2005 8 A Uniform Resource Name (URN) Formal Namespace 9 for the New Zealand Government 11 Suggested filename: 13 Status of this Memo 15 This document is an Internet-Draft and is subject to all provisions 16 of Section 3 of RFC 3667 entitled "Rights in IETF Contributions". 17 By submitting this Internet-Draft, we certify that any applicable 18 patent or other IPR claims of which we are aware have been 19 disclosed, or will be disclosed, and any of which we become aware 20 will be disclosed, in accordance with RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other 29 documents at any time. It is inappropriate to use Internet-Drafts 30 as reference material or to cite them other than as "work in 31 progress". 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/1id-abstracts.html 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). 43 Abstract 45 This document describes a Uniform Resource Name (URN) Namespace 46 Identification (NID)convention as prescribed by the World Wide Web 47 Consortium (W3C) for identifying, naming, assigning and managing 48 persistent resources and XML artefacts for the New Zealand 49 Government. 51 Discussion and comments on this draft should be sent to the authors' 52 addresses located at end of this document. 54 1. Introduction 56 The New Zealand Government has already adopted XML as its primary 57 means of storing and exchanging data. The New Zealand Government 58 publishes documents, schemas and other government artefacts. 60 The New Zealand Government now wishes to define a namespace 61 convention and structure for its agencies by creating and managing 62 globally unique, persistent, location independent identifiers for 63 their schema resources and XML artefacts. 65 This is a natural extension of the development of the Dublin Core 66 based New Zealand Government metadata standard (New Zealand 67 Government Locator Service - NZGLS) used by government agencies to 68 create metadata and made operational to the public through an 69 all-of-government portal. 71 The New Zealand Government wishes to provide guidance on namespaces 72 to its agencies so that they use a portion of the adopted namespace 73 to minimise the risk of them creating different (and potentially 74 conflicting) namespace structures. This issue potentially extends 75 to data exchange beyond government into the private sector of New 76 Zealand, thus placing the government under an obligation to provide 77 guidance in the assignment and management of additional namespaces. 79 The New Zealand Government wishes to register the country NID, NZL, 80 with the Name Specific String (NSS) split into two parts; the first 81 part being a specific sub type and the second part 82 as a . 84 As part of the URN structure the New Zealand Government wishes to 85 define and subsequently manage the "govt" specifier. It will also 86 assign additional specifiers requested by other New Zealand 87 organisations in accordance with the rules and processes proposed 88 herein. 90 The New Zealand Government hoped to make use of the two letter 91 Namespace Identifier (NID) combination for its ubiquitous country 92 code, NZ. But since there is as yet no process to register these, 93 (refer RFC 3406) the government has opted to request its well known 94 alternative three letter country code (refer ISO 3166). 96 This namespace specification requests a formal namespace. 98 Please note that this paper includes a discussion on the use of 99 diacritic marks, in particular, Maori macrons. Maori is an official 100 language of New Zealand. In recognition of the established practice 101 of publishing RFCs for a global audience in ASCII text where 102 diacritic marks are unable to be recognised, the text has been 103 presented without macrons. 105 2. Specification Template 107 Namespace ID: 109 "NZL". 111 Registration Information: 113 Version Number: 1 115 Date: 2005-03-31 117 Declared registrant of the namespace: 119 E-government Unit 121 c/o State Services Commission 123 New Zealand Government 125 100 Molesworth Street 127 Wellington, 129 New Zealand 131 Email: e-GIF@ssc.govt.nz 133 Declaration of structure: 135 The identifier has a hierarchical structure as follows: 137 urn:nzl:[:]+ 139 + denotes one or more occurrences of nz-specifier defined strings all 140 delimited by a colon. 142 For example: 144 urn:nzl:govt:registering:dogs:registration:1-0 145 urn:nzl:govt:registering:firearms:form:1-3 146 urn:nzl:govt:registering:recreational_fishing:form:1-0 148 The and can comprise any 149 UTF-8 characters compliant with URI syntax and must not contain the ":" 150 character (refer RFC 2396). The exclusion of the colon from the list 151 of other characters means that the colon can only occur as a delimiter 152 between string values. The values come from the terms listed in the 153 NZGLS. 155 The State Services Commission E-government Unit (SSC EGU) of the New 156 Zealand Government will take responsibility for the 157 "govt" and its sub level terms; e.g. 158 "registering". 160 The SSC EGU of the New Zealand Government will take responsibility to 161 assign other to organisations who apply and can satisfy 162 the SSC EGU that they have the capability to manage the sub level and 163 its applicable . 165 Relevant ancillary documentation: 167 The function and noun syntax used in the 168 is based on and taken from the NZGLS 169 (http://www.e.govt.nz/nzgls/thesauri/). 171 Identifier uniqueness considerations: 173 Identifiers in the "govt" are defined and assigned in the 174 requested namespace by the SSC EGU after ensuring that the URNs to be 175 assigned are unique. Uniqueness is achieved by checking against the 176 registry of previously assigned names. 178 The SSC EGU will ensure that the URNs to be assigned to other 179 organisations applying for other (e.g. mil, co, org) 180 are unique by checking against the registry of previously assigned 181 names. 183 The SSC EGU will develop and publish the process for doing this which, 184 where applicable, is consistent with the process it uses for moderating 185 the .govt.nz Top Level Domain (TLD). 187 Identifier persistence considerations: 189 The New Zealand Government is committed to maintaining uniqueness and 190 persistence of all resources identified by assigned URNs. 192 Given that the URN sought is NZL (the long held ISO 3166 Alpha-3 193 representation of the country) together with the country's independence 194 from any other jurisdiction expected to continue indefinitely, the URN 195 should also persist indefinitely. 197 Likewise, the "govt" has a very long life expectancy and 198 can be expected to remain unique for the foreseeable future. The 199 assignment process guarantees that names are not reassigned. The 200 binding between the name and its resource is permanent. 202 The SSC EGU will ensure that other organisations applying to manage 203 other Second Level Name (2LN) sub levels of the NZL URN 204 namespace; (e.g. mil, co, org) uniquely assign the namespace at this 205 level. 207 Process of identifier assignment: 209 Under the "NZL" NID, the New Zealand Government will manage the "govt" and leverage the existing NZGLS thesaurus for 211 identifier resources to maintain uniqueness. 213 The process of assigning URNs at the sub level will be 214 managed by the SSC EGU of the New Zealand Government. (The SSC EGU has 215 managed and maintained the NZGLS thesauri since its inception in 2002 216 as well as moderating the TLD, .govt.nz). 218 The SSC EGU will develop and publish the process for doing this which 219 is consistent with the process it uses for moderating the .govt.nz TLD, 220 where applicable. The process for marketing the ".govt.nz" TLD can be 221 found at these links: 223 http://www.e.govt.nz/docs/mod-policy/chapter1.html 225 and 227 http://www.e.govt.nz/docs/mod-policy/chapter2.html 229 and is drawn from the 2LD policies and procedures of the New Zealand 230 Office of the Domain Name Commissioner http://dnc.org.nz (and 231 specifically http://www.dnc.org.nz/story/30043-35-1.html). 233 Other New Zealand organisations may apply to the SSC EGU to delegate 234 specifiers for resolution and management assigned by them. Delegation 235 of this responsibility will not be unreasonably withheld provided the 236 processes for their resolution and management are robust and are 237 followed. 239 Organisations who apply to have a assigned to them must 240 satisfy the SSC EGU that they have the capability to responsibly manage 241 the 2LN sub level and its applicable . 242 The policies and procedures in the links above will be provided to 243 applicants as a guide and will be used by the SSC EGU to determine the 244 applicant's capability. 246 Process of identifier resolution: 248 For the "govt", the SSC EGU will maintain lists of 249 assigned identifiers on its web pages at http://www.e.govt.nz/. 251 The SSC EGU will require other organisations that apply to manage other 252 sub levels to follow this practice unless there are 253 specific reasons (e.g. security) not to do so. 255 Rules for Lexical Equivalence: 257 The lexical equivalence of the NZL namespace specific strings (NSSs) is 258 defined as an exact, but not case-sensitive string match. Best Practice 259 guidelines will specify: 261 a) NZL in either upper or lower case 262 (The New Zealand government will assign names case-insensitive, to 263 ensure that there will not be two NZL URNs differing only by case) 264 . 265 b) The first letter of each and in upper case or the whole value in lower case 268 c) Any identifier in NZL namespaces can be compared using the 269 normal mechanisms for percent-encoded UTF-8 strings. 271 Note that textual data containing diacritic marks (such as Maori 272 macrons) will not be treated as lexically equivalent to textual data 273 without diacritic marks; i.e. a distinction will be made. It is 274 important to note that a macron can change the meaning of a word in the 275 Maori language. 277 The following explanation provides guidance in this respect. 279 NSS is any UTF-8 encoded string that is compliant with the URN syntax 280 (i.e. following the encoding rules for 8-bit characters). Since Maori 281 is an official language in New Zealand and its use of diacritic marks 282 (in this case macrons) invokes the requirement to percent-encode 283 reserved characters, the following extract from 284 http://www.ietf.org/internet-drafts/draft-fielding-uri-rfc2396bis-07.txt 285 is applicable. 287 "When a new URI scheme defines a component that represents textual 288 data consisting of characters from the Unicode character set [UCS], 289 the data should be encoded first as octets according to the UTF-8 290 character encoding [STD63], and then only those octets that do not 291 correspond to characters in the unreserved set should be 292 percent-encoded. For example, the character A would be represented 293 as "A", the character LATIN CAPITAL LETTER A WITH GRAVE would be 294 represented as "%C3%80", and the character KATAKANA LETTER A would 295 be represented as "%E3%82%A2". 297 As described above, UTF-8 allows the use of diacritic marks such as New 298 Zealand Maori macrons. 300 In the New Zealand context, the word "Maori" carries a diacritic mark 301 over the "a". A URI including the macronised word "Maori" would be 302 percent-encoded as M%C4%81ori. 304 Given that the "govt" namespaces will draw from the NZGLS thesaurus 305 (that does not at present utilise diacritic marks) the "govt" 306 will not utilise UTF-8's percent encoding convention for 307 diacritic marks. An "a" with a diacritic mark will be presented simply 308 as an "a". There is no mapping or equivalence table. Therefore, the 309 requirement to distinguish between terms that have diacritic marks and 310 those that do not, will not arise in the "govt". 312 Other organisations may use diacritic marks with certain conditions. 313 Organisations that apply to manage other sub levels of 314 the NZL URN namespace could utilise UTF-8's diacritic functionality 315 provided they have the applicable processes to separate Maori language 316 terms using macrons from those that do not, in order to ensure 317 uniqueness in accordance with rule c) above. 319 Conformance with URN Syntax: 321 No special considerations. 323 Validation mechanism: 325 None other than names being derived from the NZGLS thesaurus 326 "dictionary". 328 Scope: 330 Global, but primarily of National interest. 332 3. Namespace Considerations 334 The SSC EGU undertook a preliminary study of the URI alternatives 335 against the key requirements. The options were narrowed down to five. 336 These were a private URI scheme, URL, PURL, IRI and URN. URN was 337 considered to be the most appropriate URI against the criteria. 339 Consultation on the preliminary study was actively sought from The 340 Internet Society of NZ (InternetNZ), The NZ Computer Society, 341 applicable vendors and government agencies. Publication on the 342 e-government web site allowed for public participation. 344 Points that should be noted are: 346 a) With respect to the NID, the New Zealand Government is the 347 first known jurisdiction to apply its globally known ISO 3166 348 Alpha-3 country code to become a URN. One objective of the 349 ISO 3166 Alpha-2 and 3 letter country codes was to provide 350 uniqueness 352 b) The namespace follows the logical structure of the NZGLS as 353 shown in the examples above. 355 4. Community Considerations: 357 Providers of government information for data exchange benefit by the 358 publication of the namespace because it provides much needed guidance 359 on generating target namespaces for schema development using a process 360 that reflects what they already know � namely metadata creation in NZGLS. 361 The identifiers under the "govt" specifier will track the terms used in 362 the New Zealand government thesaurus. 364 Consequently, New Zealanders will ultimately benefit since the exchange 365 of more structured information will potentially improve online 366 experiences in such areas as forms design. 368 Any citizen or organisation with Internet web browser capability will be 369 entitled to access the namespace and its associated application, 370 registration and resolution services. While the assignment of 371 identifiers will be managed by the SSC EGU, additional specifiers, such 372 as mil, co, org and their can be openly 373 applied for and registered by anyone following an approved namespace 374 governance process and proof of the applicant's bona fide association 375 with the intended specifier (i.e. no squatting or hoarding). 377 5. IANA Considerations: 379 This document includes a URN NID registration for NZL for entry in the 380 IANA registry of URN NIDs. The registration should not be actioned prior 381 to RFC publication. 383 6. Security Considerations 385 No serious security implications are envisaged beyond the potential 386 threat of spoofing. The application, registration and assignment of 387 subsequent specifiers will leverage existing government processes to 388 authenticate the applicants and their association with the proposed 389 specifier application. 391 7. Acknowledgement 393 Since the specification described in this document is derived from 394 RFC 2396 and RFC 3406, the acknowledgements in those documents still 395 apply. In addition, the authors wish to acknowledge Leslie Daigle 396 and Ted Hardie for their suggestions and review. 398 8. References: 400 8.1. Normative References 402 [1] Daigle, L., van Gulik, D., Iannella, R. and Falstrom P,. "Uniform 403 Resource Names (URN) Namespace Definition Mechanisms, RFC 3406, October 404 2002. 406 [2] Berners-Lee, T., Fielding, R. and Masinter, L,. "Uniform Resource 407 Identifiers (URI): Generic Syntax", RFC 2396, August 1998. 409 8.2. Informative References 411 [3] Berners-Lee, T., Fielding, R and Masinter L,. "Uniform Resource 412 Identifiers (URI): Generic Syntax draft-fielding-uri-rfc2396bis-07", 413 September 2004. 415 [4] Narten, T,. Alvestrand, H,. "Guidelines for Writing an IANA 416 considerations Section in RFC's", RFC 2434, October 1998. 418 [5] Bellifemine, F., Constantinescu, I., Willmott, S., "A Uniform 419 Resource Name (URN)Namespace for Foundation for Intelligent Physical 420 Agents (FIPA)", RFC 3616, September 2003. 422 [6] Mealling, M., "A Uniform Resource Name (URN) Namespace for the 423 Liberty Alliance Project", RFC 3622, February 2004. 425 [7] URI Planning Interest Group, W3C/IETF (See acknowledgments) 426 September 2001, 427