doc: Add RFC documents

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]
+