summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4617.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4617.txt')
-rw-r--r--doc/rfc/rfc4617.txt451
1 files changed, 451 insertions, 0 deletions
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]):
+
+<NID> ::= "IVIS"
+
+<NSS> ::= <IVIS Org ID>:<ResID - suffix>
+
+<IVIS Org ID> ::= 1*<number> { subsystem ID from IVIS database}
+
+<ResID - suffix> ::= 1*(<upper> | <lower> | <number> | <other>)
+{an ID generated by IVIS subsystem that is unique within
+this subsystem}
+
+
+
+
+
+
+
+
+Kornijenko Informational [Page 2]
+
+RFC 4617 IVIS URN Definition August 2006
+
+
+<other> ::= "(" | ")" | "+" | "," | "-" | "." |
+ "=" | "@" | ";" | "$" |
+ "_" | "!" | "*"
+
+<upper> ::= "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"
+
+<lower> ::= "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"
+
+<number> ::= "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 <other>.
+
+ Validation mechanism:
+
+ <IVIS Org ID> could be validated by using a special IVIS database
+ service. <ResID - suffix> 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/>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]
+