idnits 2.17.1 draft-kornijenko-ivis-urn-00.txt: 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 290. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 267. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 274. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 280. ** 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. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 79 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document obsoletes RFC3383, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC02, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (02 February 2006) is 6655 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) == Unused Reference: '1' is defined on line 207, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 211, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 216, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 220, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 223, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 227, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 230, 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: 10 errors (**), 0 flaws (~~), 11 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Jurijs Kornijenko 2 Expires in six months ABC Software 3 Obsoletes: RFC 3383 02 February 2006 5 A URN Namespace for the Latvian National Government Integration Project 6 Suggested filename: 8 Status of this Memo 10 Internet-Drafts are working documents of the Internet Engineering Task 11 Force (IETF), its areas, and its working groups. Note that other groups may 12 also distribute working documents as Internet-Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six months 15 and may be updated, replaced, or obsoleted by other documents at any 16 time. It is inappropriate to use Internet-Drafts as reference material 17 or to cite them other than as "work in progress". 19 The list of current Internet-Drafts can be accessed at 20 http://www.ietf.org/1id-abstracts.html 22 The list of Internet-Draft Shadow Directories can be accessed at 23 http://www.ietf.org/shadow.html 24 By submitting this Internet-Draft, each author represents that any 25 applicable patent or other IPR claims of which he or she is aware 26 have been or will be disclosed, and any of which he or she becomes 27 aware will be disclosed, in accordance with Section 6 of BCP 79. 29 Copyright Notice 31 Copyright (C) The Internet Society (2006).All Rights Reserved. 32 Please see the Full Copyright section near the end of this document 33 for more information. 35 Abstract 37 This document describes a Uniform Resource Name (URN) namespace that is 38 engineered by a consortium (general contractor - Olimps Ltd and 39 subcontractors - ABC software LTD, Microsoft Latvia LTD, 40 RIX Technologies LTD and Microlink LTD) for naming information resources 41 published and produced by the Latvian National Government Integration 42 Project (latvian abbreviation - IVIS). 44 1. Introduction 46 The IVIS uses and produces many kinds of information resources such as: 47 E-services, E-service instances, specifications, standards, working 48 documents, XML schemas, etc., which ID in IVIS has to be unique for 49 global use every time. 51 2. Specification Template 53 2.1 Namespace ID: 55 "IVIS" requested. 57 2.2 Registration information: 59 Registration Version Number: 1 60 Registration Date: 2006-MM-DD 62 2.3 Declared registrant of the namespace: 64 Name: Jurijs Kornijenko 65 Title: software architect 66 Affiliation: Mag.sc.ing. 67 Address: Tallinas - 51, Riga, LV-1012 68 Phone: +371 7082635 69 Email: j.kornienko@abcsoftware.lv 71 2.4 Declaration of structure: 73 The Namespace Specific String (NSS) of all URNs assigned by the 74 IVIS will have the following hierarchical structure: 76 ::= "IVIS" 78 ::= : 80 ::= { subsystem ID from IVIS database} 82 ::= | | | 83 {an ID generated by IVIS subsystem and that is unique within 84 this subsystem} 86 ::= "(" | ")" | "+" | "," | "-" | "." | 87 "=" | "@" | ";" | "$" | 88 "_" | "!" | "*" 90 ::= "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | 91 "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" | 92 "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" | 93 "Y" | "Z" 95 ::= "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | 96 "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" | 97 "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" | 98 "y" | "z" 100 ::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | 101 "8" | "9" 103 2.5 Relevant ancillary documentation: 105 IVIS ancillary documentation is under development. 107 2.6 Identifier uniqueness considerations: 109 Uniqueness is guaranteed by the IVIS that issues the numbers. 110 The numbers are not re-assigned. 112 2.7 Identifier persistence considerations: 114 Persistence of identifiers is dependent upon the persistence of 115 the system name assignment by system name holders. 117 2.8 Process of identifier assignment: 119 All the assignments of identifiers are fully controlled and managed 120 by the IVIS and its subsystems. 121 2.9 Process of identifier resolution: 123 The holders of system names are responsible for operating or delegating 124 resolution servers for the system in which they have assigned URNs. 126 2.10 Rules for Lexical Equivalence: 128 The entire URN is case-insensitive. 130 2.11 Conformance with URN syntax: 132 IVIS schema URN fully conforms to RFC2141 syntax except that symbols "'" 133 un ":" were 134 excluded from . 136 2.12 Validation mechanism: 138 could be validated by using special IVIS database service. 139 could be validated by appropriate subsystem. 141 2.13 Scope: 143 Global. 145 3. Example 147 The following examples are not guaranteed to be real. They are provided 148 for pedagogical reasons only: 150 URN:IVIS:100001:DOC-METADATA 151 URN:IVIS:100002:NDR1021365 153 4. Community Considerations 155 Every Latvian ministry, local authority produces many kinds of different 156 documents, offers public services. Each of the information resources is 157 unique identified within authority-producer already. IVIS URN namespace 158 helps to unify information resource identifiers by using existent 159 Latvian government authority identification procedures to produce 160 E-services and different documents where many parties are involved. 161 Any citizen or organization with Internet web browser capability 162 will be entitled to access the namespace and its associated 163 application, registration and resolution services. The primary IVIS 164 namespace usage is to identify information resources, such as XML 165 messages, their schemas and other recourses, which can be public 166 or have a special destination, when a few different parties are 167 involved in the interchange. 169 5. Namespace Considerations 171 To select necessary identifier schema we spend many time and made 172 decision to URN side, because IVIS URN namespace have to resolve 173 the following problems: 175 1.Information resource uniqueness 177 Uniqueness gives possibility to find necessary resource and call it 178 anytime. Uniqueness gives stability in message sending and storing 179 operations. 181 2.Namespace understandability 183 IVIS URN consists of parts, which can guarantee namespace legibility. 185 3.Information resource resolution 187 One of the IVIS namespace parts identifies the place, where resource can 188 be found (resolved). 190 So, a new URN assignment is required and individual URNs shall be 191 assigned through the process of development of each XML schema. 193 6. Security Considerations 195 There are no additional security considerations other than those 196 normally associated with the use and resolution of URNs in general. 198 Acknowledgments 200 The authors acknowledge the thoughtful contributions of Jurijs 201 Kornijenko to this document. 203 7. References: 205 7.1. Normative References 207 [1] Daigle, L., van Gulik, D., Iannella, R. and Falstrom P,. "Uniform 208 Resource Names (URN) Namespace Definition Mechanisms, RFC 3406, October 209 2002. 211 [2] Berners-Lee, T., Fielding, R. and Masinter, L,. "Uniform Resource 212 Identifiers (URI): Generic Syntax", RFC 2396, August 1998. 214 7.2. Informative References 216 [3] Berners-Lee, T., Fielding, R and Masinter L,. "Uniform Resource 217 Identifiers (URI): Generic Syntax draft-fielding-uri-rfc2396bis-07", 218 September 2004. 220 [4] Narten, T,. Alvestrand, H,. "Guidelines for Writing an IANA 221 considerations Section in RFC's", RFC 2434, October 1998. 223 [5] Bellifemine, F., Constantinescu, I., Willmott, S., "A Uniform 224 Resource Name (URN)Namespace for Foundation for Intelligent Physical 225 Agents (FIPA)", RFC 3616, September 2003. 227 [6] Mealling, M., "A Uniform Resource Name (URN) Namespace for the 228 Liberty Alliance Project", RFC 3622, February 2004. 230 [7] URI Planning Interest Group, W3C/IETF (See acknowledgments) 231 September 2001, 232