From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4617.txt | 451 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 451 insertions(+) create mode 100644 doc/rfc/rfc4617.txt (limited to 'doc/rfc/rfc4617.txt') diff --git a/doc/rfc/rfc4617.txt b/doc/rfc/rfc4617.txt new file mode 100644 index 0000000..319ee2c --- /dev/null +++ b/doc/rfc/rfc4617.txt @@ -0,0 +1,451 @@ + + + + + + +Network Working Group J. Kornijenko +Request for Comments: 4617 ABC software +Category: Informational August 2006 + + + A Uniform Resource Name (URN) Formal Namespace for + the Latvian National Government Integration Project + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This document describes a Uniform Resource Name (URN) namespace that + is engineered by a consortium (general contractor, Olimps LTD, and + subcontractors, ABC software LTD, Microsoft Latvia LTD, Riga Internet + eXchange (RIX) Technologies LTD, and Microlink LTD) for naming + information resources published and produced by the Latvian National + Government Integration Project (Latvian abbreviation IVIS). + +Table of Contents + + 1. Introduction ....................................................2 + 2. Specification Template ..........................................2 + 3. Example .........................................................4 + 4. Community Considerations ........................................4 + 5. IANA Considerations .............................................4 + 6. Namespace Considerations ........................................5 + 7. Security Considerations .........................................5 + 8. Acknowledgements ................................................5 + 9. References ......................................................6 + 9.1. Normative References .......................................6 + 9.2. Informative References .....................................6 + + + + + + + + + + + +Kornijenko Informational [Page 1] + +RFC 4617 IVIS URN Definition August 2006 + + +1. Introduction + + The IVIS uses and produces many kinds of information resources such + as E-services, E-service instances, specifications, standards, + working documents, and XML schemas. An ID in IVIS has to be unique + for global use every time. + +2. Specification Template + + Namespace ID: + + "IVIS" requested according to [RFC3406]. + + Registration information: + + Registration Version Number: 1 + Registration Date: 2006-MM-DD + + Declared registrant of the namespace: + + Organization: ABC software LTD on behalf of The Secretariat of the + Special Assignments Minister for Electronic Government Affairs + Name: Jurijs Kornijenko + Title: Software Architect + Address: Tallinas - 51, Riga, LV-1012 + Phone: +371 7082635 + Email: j.kornienko@abcsoftware.lv + + Declaration of structure: + + The Namespace Specific String (NSS) of all URNs assigned by the + IVIS will have the following hierarchical structure (ABNF, + according to [RFC4234]): + + ::= "IVIS" + + ::= : + + ::= 1* { subsystem ID from IVIS database} + + ::= 1*( | | | ) +{an ID generated by IVIS subsystem that is unique within +this subsystem} + + + + + + + + +Kornijenko Informational [Page 2] + +RFC 4617 IVIS URN Definition August 2006 + + + ::= "(" | ")" | "+" | "," | "-" | "." | + "=" | "@" | ";" | "$" | + "_" | "!" | "*" + + ::= "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" + + ::= "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" + + ::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | + "8" | "9" + + Relevant ancillary documentation: + + IVIS ancillary documentation is under development. + + Identifier uniqueness considerations: + + Uniqueness is guaranteed by the IVIS that issues the numbers. The + numbers are not reassigned. + + Identifier persistence considerations: + + Persistence of identifiers is dependent upon the persistence of + the system name assignment by system name holders. + + Process of identifier assignment: + + All the assignments of identifiers are fully controlled and + managed by the IVIS and its subsystems. + + Process of identifier resolution: + + The holders of system names are responsible for operating or + delegating resolution servers for the system in which they have + assigned URNs. + + Rules for Lexical Equivalence: + + The entire URN is case insensitive. + + + + + + +Kornijenko Informational [Page 3] + +RFC 4617 IVIS URN Definition August 2006 + + + Conformity with URN syntax: + + IVIS schema URN fully conforms to [RFC2141] syntax, except that + symbols "'" and ":" were excluded from . + + Validation mechanism: + + could be validated by using a special IVIS database + service. could be validated by an appropriate + subsystem. + + Scope: + + Global. + +3. Example + + The following examples are not to be real. They are provided for + pedagogical purposes only. + + URN:IVIS:000000:DOC-METADATA + URN:IVIS:000000:NDR1021365 + +4. Community Considerations + + Every Latvian ministry's local authority produces many kinds of + different documents, offers public services. Each of the information + resources is already uniquely identified within an authority- + producer. The IVIS URN namespace helps unify information resource + identifiers by using existent Latvian government authority + identification procedures to produce E-services and different + documents where many parties are involved. Any citizen or + organization with Internet web browser capability will be entitled to + access the namespace and its associated application, registration, + and resolution services. The primary IVIS namespace usage is to + identify information resources, such as XML messages, their schemas, + and other resources, which can be public or have a special + destination, when a few different parties are involved in the + interchange. + +5. IANA Considerations + + This document includes a RUN Network Identifier (NID) registration + for IVIS for entry in the IANA registry of URN NIDs (see [RFC2434] + for more information). + + + + + + +Kornijenko Informational [Page 4] + +RFC 4617 IVIS URN Definition August 2006 + + +6. Namespace Considerations + + To select necessary identifier schema, we spend a lot time and + decided on URN, because an IVIS URN namespace has to resolve the + following problems: + + - Information resource uniqueness + + Uniqueness makes it possible to find a necessary resource and call + it anytime. Uniqueness gives stability in message sending and + storing operations. + + - Namespace understandability + + IVIS URN consists of parts, which can guarantee namespace + legibility. + + - Information resource resolution + + One of the IVIS namespace parts identifies the place where the + resource can be found (resolved). + + Therefore, a new URN assignment is required, and individual URNs + shall be assigned through the process of development of each XML + schema. + +7. Security Considerations + + There are no additional security considerations besides those + normally associated with the use and resolution of URNs in + general. + +8. Acknowledgements + + Since the specification described in this document is derived from + [RFC3305], [RFC3616], [RFC3986], [RFC3622], and [RFC3406] the + acknowledgements in those documents still apply. In addition, the + author wishes to acknowledge Leslie Daigle, Ted Hardie, and Dinara + Suleymanova for their suggestions and review. + + + + + + + + + + + + +Kornijenko Informational [Page 5] + +RFC 4617 IVIS URN Definition August 2006 + + +9. References + +9.1. Normative References + + [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. + Faltstrom, "Uniform Resource Names (URN) Namespace + Definition Mechanisms", BCP 66, RFC 3406, October 2002. + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, RFC + 3986, January 2005. + +9.2. Informative References + + [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 2434, + October 1998. + + [RFC3305] Mealling, M. and R. Denenberg, "Report from the Joint + W3C/IETF URI Planning Interest Group: Uniform Resource + Identifiers (URIs), URLs, and Uniform Resource Names + (URNs): Clarifications and Recommendations", RFC 3305, + August 2002. + + [RFC3616] Bellifemine, F., Constantinescu, I., and S. Willmott, "A + Uniform Resource Name (URN) Namespace for Foundation for + Intelligent Physical Agents (FIPA)", RFC 3616, September + 2003. + + [RFC3622] Mealling, M., "A Uniform Resource Name (URN) Namespace + for the Liberty Alliance Project", RFC 3622, February + 2004. + + [W3C/IETF] URI Planning Interest Group, W3C/IETF September 2001, + http://www.w3.org/TR/2001/NOTE-uri- + clarification-20010921/. + + [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. + + [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for + Syntax Specifications: ABNF", RFC 4234, October 2005. + + + + + + + + + +Kornijenko Informational [Page 6] + +RFC 4617 IVIS URN Definition August 2006 + + +Author's Address + + Jurijs Kornijenko + ABC software LTD + Software Architect + Tallinas - 51 + Riga, LV-1012 + + Phone: +371 7082635 + EMail: j.kornienko@abcsoftware.lv + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kornijenko Informational [Page 7] + +RFC 4617 IVIS URN Definition August 2006 + + +Full 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. + + 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. + +Intellectual Property + + 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@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Kornijenko Informational [Page 8] + -- cgit v1.2.3