- Ietf-types - alvestrand.no

Revised draft of Last Call document (draft-miller-media-type-cellml)
by Andrew Miller 29 Jun '06

29 Jun '06

Hi all, Please find attached a revised draft of the CellML Media type registration, which is in Last Call for Informational status until 19th of July 2006. The draft has been submitted to the IETF secretariat, but will not appear until on or after Monday, Jule 10 at 9:00 AM ET, due to the upcoming IETF meeting. The revised draft differs from the previous one in the following respects: 1) It fixes a few minor ID nits: a) Minor formatting changes such as fixing a 73 character line, b) Changes a "recommended" to "RECOMMENDED", and a may to "can" to avoid confusion with MAY. 2) The draft now explicitly states that utf-8 is the only acceptable character set. This has always been in the CellML Umbrella Format, but now it is in the draft as well, for clarity. 3) The Abstract is no longer redundant with the Introduction, and the Discussion section has been merged into the Introduction. 4) An ambiguous use of the word "registry" (between the IANA types registry and the CellML Umbrella Format registry) has been fixed. Please CC any comments regarding this draft to ak.miller(a)auckland.ac.nz Best regards, Andrew Miller Internet Draft draft-miller-media-type-cellml-04.txt Intended Status: Network Working Group A. K. Miller Request for Comments: nnnn The University of Auckland Informational May 2006 CellML Media Type Status of 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 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. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress. The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html 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. Miller Informational [Page 1] RFCnnnn CellML Media Type 24 May 2006 1. Introduction CellML Umbrella format is a standardised markup meta-language for the interchange of mathematical models. CellML Umbrella Format provides a common base which is supported by a number of specific formats used in the interchange of mathematical models. 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]. 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 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 Miller Informational [Page 2] RFCnnnn CellML Media Type 24 May 2006 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 which 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 contain a document element with 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 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. Miller Informational [Page 3] RFCnnnn CellML Media Type 24 May 2006 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(a)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 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 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. Miller Informational [Page 4] RFCnnnn CellML Media Type 24 May 2006 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 this media type to the 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", RFC 2119, BCP 14, March 1997 [RFC3023] Murata, M., Simon, S.L., Kohn, D., "XML Media Types", RFC 3023, January 2001 [XML] Bray, T., et. al., "Extensible Markup Language (XML) 1.0 (Third Edition)", 4 February 2004, <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/> Miller Informational [Page 5] RFCnnnn CellML Media Type 24 May 2006 [RFC4288] Freed, N. and Klensin, J.C., "Media Type Specifications and Registration Procedures", RFC 4288, BCP 13, December 2005 Author's Address Andrew Miller The Bioengineering Institute at The University of Auckland Level 6, 70 Symonds St Auckland Central Auckland E-mail: ak.miller(a)auckland.ac.nz 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 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. Miller Informational [Page 6]

1 0

Request for review of audio/amr and audio/amr-wb media types
by Colin Perkins 29 Jun '06

29 Jun '06

The AVT working group requests media type review for the audio/amr and audio/amr-wb media types, defined in section 8.1 and 8.2 of draft- ietf-avt-rtp-amr-bis-04.txt. This draft is currently in working group last call to obsolete RFC 3267. We would be grateful if any comments could be made by 21st July 2006. Thanks, Colin Perkins (AVT co-chair)

1 0

Fwd: Last Call: 'CellML Media Type' to Informational RFC (draft-miller-media-type-cellml)
by Lisa Dusseault 22 Jun '06

22 Jun '06

FYI Begin forwarded message: > From: The IESG <iesg-secretary(a)ietf.org> > Date: June 21, 2006 2:46:33 PM PDT > To: IETF-Announce <ietf-announce(a)ietf.org> > Subject: Last Call: 'CellML Media Type' to Informational RFC > (draft-miller-media-type-cellml) > Reply-To: iesg(a)ietf.org > > The IESG has received a request from an individual submitter to > consider the > following document: > > - 'CellML Media Type ' > <draft-miller-media-type-cellml-03.txt> as an Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg(a)ietf.org or ietf(a)ietf.org mailing lists by 2006-07-19. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-miller-media-type- > cellml-03.txt > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce(a)ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce

2 1

Re: Last Call: 'CellML Media Type' to Informational RFC (draft-miller-media-type-cellml)
by Mark Baker 22 Jun '06

22 Jun '06

Yah, we (ietf-types) reviewed this one pretty thoroughly a few weeks ago, and -03 reflects the results of that review. http://www.alvestrand.no/pipermail/ietf-types/2006-March/date.html http://www.alvestrand.no/pipermail/ietf-types/2006-April/date.html http://www.alvestrand.no/pipermail/ietf-types/2006-May/date.html Mark. On 6/22/06, Lisa Dusseault <lisa(a)osafoundation.org> wrote: > > FYI > > Begin forwarded message: > > From: The IESG <iesg-secretary(a)ietf.org> > Date: June 21, 2006 2:46:33 PM PDT > To: IETF-Announce <ietf-announce(a)ietf.org> > Subject: Last Call: 'CellML Media Type' to Informational RFC > (draft-miller-media-type-cellml) > Reply-To: iesg(a)ietf.org > > > The IESG has received a request from an individual submitter to consider the > following document: > > - 'CellML Media Type ' > <draft-miller-media-type-cellml-03.txt> as an > Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg(a)ietf.org or ietf(a)ietf.org mailing lists by 2006-07-19. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-miller-media-type-cellml-03.txt > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce(a)ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce > >

1 0

Registration of media type application/sparql-results+json
by Elias Torres 16 Jun '06

16 Jun '06

see also http://www.w3.org/2001/sw/DataAccess/json-sparql/#mediaType Type name: application Subtype name: sparql-results+json Required parameters: None Optional parameters: None Encoding considerations: The encoding considerations of the SPARQL Query Results JSON Format is identical to those of the "application/json" as specified in [JSON-IETF-DRAFT] Security considerations: SPARQL query results uses URIs. See Section 7 of [RFC3986]. SPARQL query results uses IRIs. See Section 8 of [RFC3987]. The security considerations of the SPARQL Query Results JSON Format is identical to those of the "application/json" as specified in [JSON-IETF-DRAFT] Interoperability considerations: There are no known interoperability issues. Published specification: http://www.w3.org/2001/sw/DataAccess/json-sparql/ Applications which use this media type: No known applications currently use this media type. Additional information: Magic number(s): n/a File extension(s): ".srj" Macintosh file type code(s): "TEXT" Person & email address to contact for further information: Kendall Clark, Elias Torres, Lee Feigenbaum <public-rdf-dawg-comments(a)w3.org> Intended usage: COMMON Restrictions on usage: None Author/Change controller: The SPARQL specification is a work product of the World Wide Web Consortium's RDF Data Access Working Group. The W3C has change control over these specifications. References [JSON-IETF-DRAFT] JavaScript Object Notation (JSON), Internet Draft, D. Crockford, http://www.ietf.org/internet-drafts/draft-crockford-jsonorg-json-04.txt Regards, Elias Torres Member of RDF Data Access Working Group W3C/IBM

2 1

Request for review: application/cellml+xml
by Andrew Miller 25 May '06

25 May '06

Hi all, A revised Internet draft, http://www.ietf.org/internet-drafts/draft-miller-media-type-cellml-03.txt, has been published to replace draft-miller-media-type-cellml-02.txt. This draft changes the recommended file extension from .xml to .cellml, and recommends the use of .cellml when saving somewhere where file extensions matter. This extension has now been endorsed by the CellML team as the official CellML file extension. Best regards, Andrew Miller

2 1

[spam] The best pils f0r men health by l0wer prices!
by Miriam 23 May '06

23 May '06

1 0

Request for reviewing audio, vidoe, text/rtp-enc-aescm128
by Magnus Westerlund 23 May '06

23 May '06

This is a request to review the media types: audio/rtp-enc-aescm128 video/rtp-enc-aescm128 text/rtp-enc-aescm128 These have been requested by 3GPP SA4 to be registered in the standards tree by the IESG following the SDO rules in RFC 4288. The type registration is present in Technical Specification 26.234 in section K.1.4.1: http://www.3gpp.org/ftp/Specs/archive/26_series/26.234/26234-670.zip It is reproduced below for your information. The full media format is specified in Annex K of above specification. The registration template has been present in the document for a while and follows the template in RFC 2048. If that is a problem it can be fixed, however it will take some months. I therefore would also like to receive any further comments in that case. MIME media type name: audio, video, text MIME subtype name: rtp-enc-aescm128 Required parameters: opt: The payload type number of the payload type contained in the encrypted payload. An integer value between 0-127. rate: The timestamp rate of this payload type, which shall be the same as that of the original payload type. This is an integer value between 1 and 2^32. ContentID: The OMA DRM content ID [75] used to identify the content when establishing a crypto context. The value is an RFC 2396 [60] URI, which shall be quoted using <">. RightsIssuerURL: The right issuer URL as defined by OMA DRM [75]. The value is an URI in accordance with RFC 2396 [60], which shall be quoted using <">. IVnonce: The value of this parameter is the nonce that forms the IV as specified by the crypto transform, encoded using Base 64 [69]. Optional parameters: SelectiveEncryption: Indicates if this stream is selectively encrypted. Allowed values are 0 (false) and 1 (true). If not present, selective encryption shall not be used. Please note that unless this indicator is integrity protected, it fulfills no purpose. Encoding considerations: This type is only defined for transfer via RTP (RFC 3550). Security considerations: See considerations raised in RTP RFC 3550 [9] and any applicable profile like RFC 3551 [10] or RFC 3711 [72]. Further see 3GPP TS 26.234, Release 6, Annex K for comments on security issues. The main issues that exists are: - This RTP payload format only confidentiality protects the RTP payload, thus header information is leaked, similarly to SRTP. - The use of stream ciphers as AES CM and no integrity protection allows an attacker to purposefully attack the content of the encrypted RTP payload by switching individual bits. - The usage of selective encryption without integrity protection allows for an attacker to perform any replacements of complete RTP payloads and packets it desires. - The payload format makes the receiver vulnerable to denial of service attacks that inserts RTP packets into the stream, that the receiver then interprets as being encrypted thus wasting computational resources. To prevent this attack, authentication needs to be used. Interoperability considerations: Published specification: 3GPP TS 26.234, Release 6. Open Mobile Alliance DRM Content Format V2.0 Applications which use this media type: Third Generation Partnership Project (3GPP) Packet-switched Streaming Service (PSS) clients and servers, which supports the Open Mobile Alliance's specification of Digital Rights Management version 2.0. Additional information: Magic number(s): N/A File extension(s): N/A Macintosh File Type Code(s): N/A Person & email address to contact for further information: magnus.westerlund(a)ericsson.com Intended usage: Common Author/Change controller: 3GPP TSG SA --- Thanks Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund(a)ericsson.com

4 4

Registration of media type "application/oebps-package+xml"
by Nick Bogaty 16 May '06

16 May '06

To whom it may concern, Apologies for not including the template for community review of the mime type "application/oebps-package+xml". It is as follows: Type name: application Subtype name: oebps-package+xml Required parameters: none Optional parameters: none Encoding considerations: UTF-8 or UTF-16 (XML) Security considerations: none Interoperability considerations: none Published specification: http://www.idpf.org/oebps/oebps1.2/download/oeb12-xhtml.htm Applications that use this media type: 1) eBook Technologies, Inc. eBook reading system. 2) Microsoft Reader. 3) OSoft reader.4) Content Reserve Publishing System 5) IDPF (container WG) 6) PC Reader.com 7) MobiPocket reader Additional information: Magic number(s): none File extension(s): .opf Macintosh file type code(s): none Person & email address to contact for further information: Nick Bogaty (nbogaty(a)idpf.org) Intended usage: COMMON (One of COMMON, LIMITED USE or OBSOLETE.) Restrictions on usage: none (Any restrictions on where the media type can be used go here.) Author: International Digital Publishing Forum (www.idpf.org <http://www.idpf.org/> ) Change controller: International Digital Publishing Forum (www.idpf.org <http://www.idpf.org/> ) (Any other information that the author deems interesting may be added below this line.) Some discussion of Macintosh file type codes and their purpose can be found in [MacOSFileTypes]. Additionally, please refrain from writing "none" or anything similar when no file extension or Macintosh file type is specified, lest "none" be confused with an actual code value. -----Original Message----- From: Nick Bogaty [mailto:nbogaty@idpf.org] Sent: Friday, April 28, 2006 1:29 PM To: 'iesg(a)ietf.org'; 'ietf-types(a)iana.org' Cc: 'Garth Conboy'; 'John Rivlin'; 'Jon Ferraiolo' Subject: Community Review & IESG Approval of Media Type for OEBPS package standard To whom it may concern, As per the instructions for registering MIME types in the Standards tree with the IETG/IANA ( <ftp://ftp.rfc-editor.org/in-notes/rfc4288.txt> ftp://ftp.rfc-editor.org/in-notes/rfc4288.txt) I am submitting the following potential media type registration for preliminary community review with the aim of IESG approval before submission to the IANA. I am the Executive Director of a small standards organization devoted to digital texts and electronic books called the International Digital Publishing Forum (www.idpf.org) We created and maintain a standard widely used by the publishing industry to create electronic books called the Open eBook Publication Structure (OEBPS). That specification can be found at http://www.idpf.org/oebps/oebps1.2/index.htm. The OEBPS specification states that there must be something called an OEBPS package file which specifies OEBPS documents, images, and other objects that make up an entire OEBPS publication. What we are looking to do is to formally register a MIME Type for this package file in the standards tree. Specifically, we are seeking to register the following MIME Type for the OEBPS package: "application/oebps-package+xml". If this submission requires additional information for community review and IESG approval, please let me know. Best, Nick Bogaty -- Nick Bogaty Executive Director International Digital Publishing Forum (IDPF) nbogaty(a)idpf.org www.idpf.org (212) 924-9081 direct (212) 208-0978 fax

3 2

Re: Request for reviewing audio, vidoe, text/rtp-enc-aescm128
by Magnus Westerlund 16 May '06

16 May '06

Russ Housley wrote: > Magnus: > > The security considerations clearly indicate the problems with AES > Counter Mode. There are alternatives that provide efficient integrity > protection. Why would we want to permit this fragile encryption mode > when robut alternatives are available? At a minimum, the registration > should tell us. > > Russ >> >> Security considerations: >> >> See considerations raised in RTP RFC 3550 [9] and any applicable >> profile like RFC 3551 [10] or RFC 3711 [72]. Further see 3GPP TS >> 26.234, Release 6, Annex K for comments on security issues. The main >> issues that exists are: >> >> - This RTP payload format only confidentiality protects the RTP >> payload, thus header information is leaked, similarly to SRTP. >> >> - The use of stream ciphers as AES CM and no integrity protection >> allows an attacker to purposefully attack the content of the encrypted >> RTP payload by switching individual bits. >> >> - The usage of selective encryption without integrity protection >> allows for an attacker to perform any replacements of complete RTP >> payloads and packets it desires. >> >> - The payload format makes the receiver vulnerable to denial of >> service attacks that inserts RTP packets into the stream, that the >> receiver then interprets as being encrypted thus wasting computational >> resources. To prevent this attack, authentication needs to be used. >> Okay, there is a integrity and authentication available for the transport using SRTP as part of the solution described in section K of TS 26.234. I can't remember why counter mode was chosen, I will try to refresh my mind by talking to some people. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund(a)ericsson.com

1 0