wdiff rfc4708.original rfc4708.txt

Internet Draft
draft-miller-media-type-cellml-05.txt

Intended Status:
Network Working Group A. K. Miller
Request for Comments: nnnn Comment: 4708 The University of Auckland
Category: Informational May October 2006

CellML Media Type

Status of this This Memo

By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of

This memo provides information for the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. community. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress.

The list does
not specify an Internet standard of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html

The list any kind. Distribution of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html this
memo is unlimited.

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 which 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 information 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.

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 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]. Specification [CELLML-UMBRELLA].

Applications which that use this media type: As per Section 4.2 of this
document.

Additional information:

Magic number(s): None.
XML processing software can identify CellML Umbrella documents
as XML documents which 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 which 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 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
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 which use that Use CellML Umbrella format 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 archive, and annotate models.

5. Security Considerations

As CellML Umbrella is an XML based XML-based markup language, all the security
considerations presented in section 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.

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 will add has added this media
type to the 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> <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", RFC 2119, BCP 14, RFC 2119, March 1997 1997.

[RFC3023] Murata, M., Simon, S.L., St. Laurent, S., and D. Kohn, D., "XML
Media Types", RFC 3023, January 2001 2001.

[XML] Bray, T., et. al., "Extensible Markup Language
(XML) 1.0 (Third (Fourth Edition)", 4 February 2004, 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, J.C., "Media Type
Specifications and Registration Procedures",
RFC 4288, BCP
13, RFC 4288, December 2005 2005.

Author's Address

Andrew Miller
The Bioengineering Institute at The University of Auckland
Level 6, 70 Symonds St
Auckland Central
Auckland

E-mail:

EMail: ak.miller@auckland.ac.nz

Full Copyright Statement

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 translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and derivative
works. However, this document itself may not be modified in any
way, such as by removing the copyright notice or references to the
Internet Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards
process must be followed, or as required to translate it into
languages other than English.

The limited permissions granted above are perpetual and will not
be revoked by the Internet Society or its successors or assigns.

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).