doc: Add RFC documents

1 files changed, 395 insertions, 0 deletions

diff --git a/doc/rfc/rfc4708.txt b/doc/rfc/rfc4708.txt
new file mode 100644
index 0000000..a7fe918
--- /dev/null
+++ b/doc/rfc/rfc4708.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                          A. Miller
+Request for Comment: 4708                     The University of Auckland
+Category: Informational                                     October 2006
+
+
+                           CellML Media Type
+
+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 standardises a new media type -- application/cellml+xml
+   -- for use in exchanging mathematical models represented in a CellML
+   Umbrella 1.0 compliant markup language.
+
+1.  Introduction
+
+   The CellML Umbrella format is a standardised markup meta-language for
+   the interchange of mathematical models.  The CellML Umbrella format
+   provides a common base that is supported by a number of specific
+   formats used in the interchange of mathematical models.  The CellML
+   Umbrella format provides enough information to determine which
+   specific language is used to express the model.  The syntax and
+   semantics of the CellML Umbrella format are defined by
+   [CELLML-UMBRELLA].
+
+   The CellML Umbrella format is an actual media format.  Although
+   CellML Umbrella documents contain elements in namespaces defined by
+   other specifications such as [RDF] and [MATHML], the elements in
+   these namespaces do not contain sufficient information to define a
+   mathematical model, and so CellML provides the information required
+   to interconnect the different CellML components, as well as the
+   information required to link CellML components to their metadata.  As
+   such, CellML Umbrella documents are more than just a collection of
+   entities defined elsewhere, and so a new media type is required to
+   identify CellML.
+
+   As all well-formed CellML Umbrella documents are also well-formed XML
+   documents, the convention described in Section 7 of [RFC3023] has
+   been observed by use of the +xml suffix.
+
+
+
+Miller                       Informational                      [Page 1]
+
+RFC 4708                   CellML Media Type                October 2006
+
+
+   The information in CellML Umbrella documents cannot be interpreted
+   without understanding the semantics of the XML elements used to mark
+   up the model structure.  Therefore, the application top-level type is
+   used instead of the text top-level type.
+
+2.  Notational Conventions
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+   The terms "element" and "document element" in this document are to be
+   interpreted as in [XML].
+
+   The term "XML namespace" is to be interpreted as in [NAMESPACES].
+
+3.  Media Type Registration for CellML Umbrella
+
+   MIME media type name: application
+
+   MIME subtype name: cellml+xml
+
+   Mandatory parameters: none
+
+   Optional parameters: charset
+
+      The charset parameter of application/cellml+xml is handled in the
+      same fashion as for application/xml, as specified in Section 3.2
+      of [RFC3023].  However, per conformance rule 4 of
+      [CELLML-UMBRELLA], valid CellML Umbrella documents MUST be in the
+      UTF-8 character set.  If the charset parameter is present, it MUST
+      take the value "utf-8".  CellML processing software SHOULD check
+      the charset field, and if it is present but not equal to "utf-8",
+      MAY attempt to recover from the error by processing the document
+      in the specified character set.
+
+   Encoding considerations: As per Section 3.2 of [RFC3023].
+
+   Security considerations: As per Section 5 of this document.
+
+   Interoperability considerations: As per Section 4.1 of this document.
+
+   Published specification:
+
+      CellML Umbrella Specification [CELLML-UMBRELLA].
+
+   Applications that use this media type: As per Section 4.2 of this
+      document.
+
+
+
+Miller                       Informational                      [Page 2]
+
+RFC 4708                   CellML Media Type                October 2006
+
+
+   Additional information:
+
+      Magic number(s): None.
+         XML processing software can identify CellML Umbrella documents
+         as XML documents that contain a document element with the local
+         name "model".
+
+      File extension(s):
+         The RECOMMENDED file extension for CellML Umbrella documents is
+         .cellml
+
+         Some older software uses the file extension .xml.  Software
+         vendors have also used the non-standard extension .cml.  In
+         contexts where the MIME type is available, or where the type
+         has already been determined as CellML, implementations SHOULD
+         allow files to be opened regardless of the extension.
+         Implementations transferring models to an environment that uses
+         file extensions SHOULD use the .cellml extension.
+
+      Macintosh File Type Code(s): "TEXT"
+
+      Person & email address to contact for further information:
+         See the Author's Address section of this document.
+
+      Intended usage: COMMON
+
+      Author/Change controller: The CellML Umbrella 1.0 specification
+         was authored by Andrew Miller.
+
+         The CellML Umbrella 1.0 specification itself will not change.
+         However, the umbrella specification defines the process for new
+         specific formats to be registered.  The Bioengineering
+         Institute at The University of Auckland, with input from the
+         CellML Community via the cellml-discussion@cellml.org mailing
+         list, has control over the CellML Umbrella Format Registry.
+
+4.  Interoperability and Usage
+
+4.1.  Interoperability Considerations
+
+   The interoperability considerations in Section 3.1 of [RFC3023] also
+   apply to CellML Umbrella documents.  CellML Umbrella documents
+   contain XML elements defined by each specific format, all of which
+   are published specifications.  In addition to the ability to parse
+   XML, user agents require software support for the semantics of [RDF]
+   and/or part or all of a specific format.  As efforts are made to keep
+
+
+
+
+
+Miller                       Informational                      [Page 3]
+
+RFC 4708                   CellML Media Type                October 2006
+
+
+   the number of specific formats small, user agents SHOULD implement
+   all specific formats listed in the CellML Umbrella Format Registry at
+   the time they were developed.
+
+4.2.  Applications that Use CellML Umbrella Format
+
+   CellML Umbrella is device-, platform-, and vendor-neutral and is
+   supported by a wide range of CellML processing tools, including those
+   designed to validate, edit, and/or visualise CellML models, extract
+   MathML or RDF, translate to or from other related specifications,
+   evaluate mathematics and ordinary differential equations, fit
+   parameters to models, and serve, archive, and annotate models.
+
+5.  Security Considerations
+
+   As CellML Umbrella is an XML-based markup language, all the security
+   considerations presented in Section 10 of [RFC3023] also apply to
+   CellML Umbrella.
+
+   Some types of CellML Umbrella documents can refer to other Uniform
+   Resource Locators (URLs) in a number of places:
+
+      i)   References to XML document type definitions or schemas.
+
+      ii)  References to other models using the import features of some
+           specific formats.
+
+      iii) References to other documents embedded in user-defined data.
+
+   Some types of CellML processing software may then automatically
+   attempt to access the URL and retrieve the document.  This retrieval
+   could have several consequences, specifically,
+
+      i)   if a CellML document is transferred via e-mail, the fact that
+           the recipient has opened the CellML document could be
+           disclosed to the sender without the recipient's knowledge or
+           consent.
+
+      ii)  where the recipient of a document transfers the document to
+           another location using the MIME type defined in this
+           document, the original author of the document may be notified
+           of the second address by the attempted retrieval of further
+           documents.
+
+      iii) by performing requests on the recipient's behalf, the CellML
+           processing software may cause actions to be performed with
+           privileges granted to the recipient, without the recipient's
+           knowledge or consent.
+
+
+
+Miller                       Informational                      [Page 4]
+
+RFC 4708                   CellML Media Type                October 2006
+
+
+   CellML processing software can mitigate this threat when running in
+   an environment where it is a concern by requiring explicit
+   confirmation from the user before attempting to load any external
+   documents.
+
+6.  IANA Considerations
+
+   This document specifies a new media type.  IANA has added this media
+   type to their media types registry as specified in [RFC4288].
+
+7.  References
+
+7.1.  Normative References
+
+   [CELLML-UMBRELLA] Miller, A.K., "CellML Umbrella Specification 1.0",
+                     20 April 2006, <http://www.cellml.org/
+                     specifications/cellml_umbrella_1.0>
+
+   [NAMESPACES]      Bray, T., et. al., "Namespaces in XML 1.1", 4
+                     February 2004, <http://www.w3.org/TR/xml-names11>
+
+   [RFC2119]         Bradner, S., "Key words for use in RFCs to Indicate
+                     Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3023]         Murata, M., St. Laurent, S., and D. Kohn, "XML
+                     Media Types", RFC 3023, January 2001.
+
+   [XML]             Bray, T., et. al., "Extensible Markup Language
+                     (XML) 1.0 (Fourth Edition)", 29 September 2006,
+                     <http://www.w3.org/TR/REC-xml/>
+
+7.2.  Informative References
+
+   [MATHML]          Ion, P. and Miner, R.(editors) "Mathematical Markup
+                     Language (MathML) 1.01 Specification", 7 July 1999,
+                     <http://www.w3.org/TR/REC-MathML/>
+
+   [RDF]             Beckett, D.(editor) "RDF/XML Syntax Specification
+                     (Revised)", 10 February 2004,
+                     <http://www.w3.org/TR/rdf-syntax-grammar/>
+
+   [RFC4288]         Freed, N. and J. Klensin, "Media Type
+                     Specifications and Registration Procedures", BCP
+                     13, RFC 4288, December 2005.
+
+
+
+
+
+
+
+Miller                       Informational                      [Page 5]
+
+RFC 4708                   CellML Media Type                October 2006
+
+
+Author's Address
+
+   Andrew Miller
+   The Bioengineering Institute at The University of Auckland
+   Level 6, 70 Symonds St
+   Auckland Central
+   Auckland
+
+   EMail: ak.miller@auckland.ac.nz
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Miller                       Informational                      [Page 6]
+
+RFC 4708                   CellML Media Type                October 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).
+
+
+
+
+
+
+
+Miller                       Informational                      [Page 7]
+