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.