idnits 2.17.1 draft-miller-media-type-cellml-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.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 319. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** 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. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. 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 1) being 321 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 (March 2006) is 6588 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'CELLML' -- Possible downref: Non-RFC (?) normative reference: ref. 'NAMESPACES' ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 4288 (Obsoleted by RFC 6838) Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft 2 draft-miller-media-type-cellml-00.txt 4 Intended Status: 5 Network Working Group A. K. Miller 6 Request for Comments: nnnn The University of Auckland 7 Standards Track March 2006 9 CellML Media Type 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress. 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 This document standardises a new media type -- 41 application/cellml+xml -- for use in exchanging mathematical models 42 represented in the CellML markup language. 44 1. Introduction 46 CellML is a standardised markup language for the interchange of 47 mathematical models. The syntax and semantics of CellML is defined 48 by [CELLML]. To enable the exchange of CellML documents, this 49 document standardises a new media type -- 50 application/cellml+xml -- for use in exchanging mathematical models 51 represented in the CellML markup language. 53 2. Notational Conventions 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 57 document are to be interpreted as described in [RFC2119]. 59 The terms "element" and "document element" in this document are to be 60 interpreted as in [XML]. 62 The term "component" in this document is to be interpreted as in 63 [CELLML]. 65 The term "XML MIME entity" is to be interpreted as in [RFC3023]. 67 The term "XML namespace" is to be interpreted as in [NAMESPACES]. 69 3. Discussion 71 CellML is an XML-based markup language for the interchange of 72 mathmatical models. It is defined by [CELLML]. 74 CellML is an actual media format. Although CellML documents contain 75 elements defined by [MATHML] and [RDF], the information in these 76 namespaces do not contain sufficient information to define a 77 mathematical model, and so CellML provides the information required 78 to interconnect the different CellML components, as well as the 79 information required to link CellML components to their metadata. 80 As such, CellML documents are more than just a collection of MathML 81 or RDF entities, and so a new media type is required to identify 82 CellML. 84 As all well-formed CellML documents are also well-formed XML 85 documents, the convention described in Section 7 of [RFC3023] has 86 been observed by use of the +xml suffix. 88 The information in CellML documents cannot be interpreted without 89 understanding the semantics of the XML elements used to mark up the 90 model structure. Therefore, the application top-level type is used 91 instead of the text top-level type. 93 New versions of the CellML specification are released from time to 94 time. All versions of the CellML specification are encoded in 95 XML, and utilise namespaces to denote their version. CellML 96 processing software SHOULD check the namespace of the document 97 element in order to determine whether or not they have the 98 capability to process a given document. 100 4. Media Type Registration 102 MIME media type name: application 104 MIME subtype name: cellml+xml 106 Mandatory parameters: none 108 Optional parameters: charset and version 110 The charset parameter of application/cellml+xml is handled in the 111 same fashion as for application/xml, as specified in Section 3.2 112 of [RFC3023]. 114 The version parameter of application/cellml+xml specifies the 115 version of the CellML specification to which the document 116 conforms. This information is also present in the content of the 117 XML MIME entity, as the namespace of the top-level element. As all 118 versions of the CellML specification provide a unique namespace in 119 a particular form, the rule to map a CellML namespace to a version 120 parameter is as follows: 122 i) Remove the prefix "http://www.cellml.org/cellml/" from the 123 namespace. 124 ii) Remove the suffix "#" from the resulting string. 126 As an example, the namespace "http://www.cellml.org/cellml/1.0#" 127 corresponds to a version attribute of "1.0". Likewise, the 128 namespace "http://www.cellml.org/cellml/1.1#" corresponds to a 129 version attribute of "1.1". 131 A MIME encoder MUST NOT produce an XML MIME entity with the 132 application/cellml+xml media type and with a version parameter 133 which does not correspond to the namespace of the document 134 element. 136 Although the version parameter is redundant when used to produce 137 an XML MIME entity, it MAY also be included in the Accept header 138 of a HTTP request[RFC2616], in order to request that a document 139 conforming to a certain version of the CellML specification be 140 served. 142 Encoding considerations: As per Section 3.2 of [RFC3023]. 144 Security considerations: As per Section 5 of this document. 146 Interoperability considerations: The interoperability considerations 147 in Section 3.1 of [RFC3023] also apply to CellML documents. CellML 148 documents contain XML elements defined by [CELLML], [MATHML], and 149 [RDF], all of which are published specifications. In addition to 150 the ability to parse XML, user agents require software support for 151 the semantics of one or more of these three specifications to use 152 the information in CellML documents. 154 Published specification: CellML Specifications[CELLML]. 156 Applications which use this media type: CellML is device-, 157 platform-, and vendor-neutral and is supported by a wide range of 158 CellML processing tools, including those designed to validate, 159 edit, and/or visualise CellML models, extract MathML or RDF, 160 translate to or from other related specifications, evaluate 161 mathematics and ordinary differential equations, and fit 162 parameters to models. 164 Additional information: 166 Magic number(s): None. 167 XML processing software may identify CellML documents as XML 168 documents which contain a document element with local name 169 "model" and a namespace URI beginning with 170 "http://www.cellml.org/cellml/". 172 File extension(s): 173 The recommended file extension for CellML documents is .xml 175 Some older CellML processing software still uses the obsolete 176 file extension .cml 178 Macintosh File Type Code(s): "TEXT" 180 Person & email address to contact for further information: 181 See the Author's Address section of this document. 183 Intended usage: COMMON 185 Author/Change controller: The CellML specification was authored 186 through the collaboration of a number of individuals, including: 188 Autumn Cuellar 189 Poul Nielsen 190 Matt Halstead 191 David Bullivant 192 David Nickerson 193 Warren Hedley 194 Melanie Nelson 195 Catherine Lloyd 197 The CellML specification is controlled 198 by the Bioengineering Institute at The University of Auckland, 199 with input from the CellML Community via the 200 cellml-discussion@cellml.org mailing list. 202 5. Security Considerations 204 As CellML is an XML based markup language, all the security 205 considerations presented in section 10 of [RFC3023] also apply to 206 CellML. 208 CellML documents can refer to other Uniform Resource Locators (URLs) 209 in a number of places: 210 i) References to XML document type definitions or schemas. 211 ii) References to other models using the CellML import feature. 212 iii) References to other documents embedded in user-defined data. 214 Some types of CellML processing software may then automatically 215 attempt to access the URL and retrieve the document. This retrieval 216 could have several consequences, specifically, 217 i) if a CellML document is transferred via e-mail, the fact that 218 the recipient has opened the CellML document could be 219 disclosed to the sender without the recipient's knowledge or 220 consent. 221 ii) where the recipient of a document transfers the document to 222 another location using the MIME type defined in this 223 document, the original author of the document may be notified 224 of the second address by the attempted retrieval of further 225 documents. 226 iii) by performing requests on the recipient's behalf, the CellML 227 processing software may cause actions to be performed with 228 privileges granted to the recipient, without the recipient's 229 knowledge or consent. 231 CellML processing software can mitigate this threat when running in 232 an environment where it is a concern by requiring explicit 233 confirmation from the user before attempting to load any external 234 documents. 236 6. IANA Considerations 238 This document specifies a new media type. IANA will add this media 239 type to the media types registry as specified in [RFC4288]. 241 7. References 242 7.1. Normative References 244 [CELLML] Cuellar, et. al. "CellML 1.1 Specification", 245 6 November 2002, 246 248 [NAMESPACES] Bray, T., et. al., "Namespaces in XML 1.1", 249 4 February 2004, 251 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 252 Requirement Levels", RFC 2119, BCP 14, March 1997 254 [RFC3023] Murata, M., Simon, S.L., Kohn, D., "XML Media 255 Types", RFC 3023, January 2001 257 [XML] Bray, T., et. al., "Extensible Markup Language 258 (XML) 1.0 (Third Edition)", 4 February 2004, 259 261 7.2. Informative References 262 [MATHML] Ion, P. and Miner, R.(editors) "Mathematical Markup 263 Language (MathML) 1.01 Specification", 7 July 1999, 264 266 [RDF] Beckett, D.(editor) "RDF/XML Syntax Specification 267 (Revised)", 10 February 2004, 268 270 [RFC2616] Fielding, R.T., et. al., "Hypertext Transfer 271 Protocol -- HTTP/1.1", RFC 2616, June 1999 273 [RFC4288] Freed, N. and Klensin, J.C., "Media Type 274 Specifications and Registration Procedures", 275 RFC 4288, BCP 13, December 2005 277 Author's Address 279 Andrew Miller 280 The Bioengineering Institute at The University of Auckland 281 Level 6, 70 Symonds St 282 Auckland Central 283 Auckland 285 E-mail: ak.miller@auckland.ac.nz 287 Full Copyright Statement 289 Copyright (C) The Internet Society (2006). 291 This document is subject to the rights, licenses and restrictions 292 contained in BCP 78, and except as set forth therein, the authors 293 retain all their rights. 295 This document and translations of it may be copied and furnished 296 to others, and derivative works that comment on or otherwise 297 explain it or assist in its implementation may be prepared, copied, 298 published and distributed, in whole or in part, without 299 restriction of any kind, provided that the above copyright notice 300 and this paragraph are included on all such copies and derivative 301 works. However, this document itself may not be modified in any 302 way, such as by removing the copyright notice or references to the 303 Internet Society or other Internet organizations, except as needed 304 for the purpose of developing Internet standards in which case the 305 procedures for copyrights defined in the Internet Standards 306 process must be followed, or as required to translate it into 307 languages other than English. 309 The limited permissions granted above are perpetual and will not 310 be revoked by the Internet Society or its successors or assigns. 312 This document and the information contained herein 313 are provided on an "AS IS" basis and THE CONTRIBUTOR, THE 314 ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE 315 INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 316 ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 317 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 318 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 319 OR FITNESS FOR A PARTICULAR PURPOSE.