- Ietf-types - alvestrand.no

[Fwd: WGLC: draft-ietf-mmusic-rfc2326bis-22]
by Magnus Westerlund 23 Sep '09

23 Sep '09

Hi, This document contains one media type (text/parameters) that we appreciate comments on before the end of the WG last call on the 19th of October. The registration is present in section 22.16. Thanks Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund(a)ericsson.com ----------------------------------------------------------------------

1 0

Re: [sipcore] When to use SIP INFO and SIP INFO-Package
by Eric Burger 23 Sep '09

23 Sep '09

How about this: 1. If someone tries to register a MIME type that will "only" be used for SIP, there is a near 100% likelihood the registration will not pass expert review. Thus you will not have a standard INFO usage. Dean explains why: MIME describes multimedia content. MIME does not describe multimedia use. 2. If someone tries to document a *new* legacy use of INFO that does not use the INFO Framework, there is a near 100% likelihood the document will neither pass expert review nor succeed as an individual informational submission, as the INFO Framework draft makes clear why such documentation may harm the Internet. [Old legacy usages were encouraged to be published, but the only usage that I know of that anyone will publish the IETF has not published yet is MSML, and that is stuck behind two drafts in final, final edits in MEDIACTRL.] 3. IETF will use the INFO Framework for all new INFO usages. Any proprietary use of INFO that does not use the INFO Framework will not be an IETF standard. 4. 3GPP (IMS) will use the INFO Framework. Any proprietary use of INFO that does not use the INFO Framework will not be an IMS standard. 5. All of your competitors will do their best to advertise how your product is totally proprietary and is likely to fail in the field. Moreover, your competitors will advertise how your product can harm the Internet. Finally, if someone *does* register your "magic MIME type", which is something that is quite possible to happen, *YOUR* customers will have to replace / upgrade / remove *YOUR* equipment. Most customers in the telecom space will see that and immediately tell you to build to the standards. Said differently, your product managers will not be very happy with someone who suggests one builds a product one cannot sell or even give away. Given the above, like many people have said, the legacy INFO method "works," in that you can build a non-interoperable, non-standard, totally proprietary, should not be connected to the Internet product. I would also offer such products are a little bit outside the charter of the IETF. We work to build interoperable, standards-based, open, Internet products that people can use safely. Even 3GPP and the ITU-T, for all of the ills many in the IETF would accuse them of, would not consider such a proposal. On Sep 22, 2009, at 8:54 PM, Linyi TIAN wrote: > Hi, Dean Willis, et al. > > I have to say I like your answers which clarify my doubts. May I > suggest > adding some words in " 6. Legacy Uses of INFO" to clarify the new > SIP INFO > Package approach and Content Type Approach? Maybe in the introduction > section we can add more information about the Content Type approach. > I mean > not only talking about the JPEG example. Even in controlled Content- > Type > there maybe issues too as Dean said. > > Current working in introduction section leads me to think about new > method > is only applicable for not-controlled Conent-Type. > > Quote from Dean's email, rewording maybe > needed > --------------------------------------------------------------------- > The MIME type model defines only "what an object is", not "how the > object can be used". To negotiate around "how the object will be used > in this application", we need a higher-level of specification and > negotiation. IN SIP INFO messages, the INFO package definition > provides that level of specification and negotiation. > > in countless application scenarios that the MIME type registration > has no > way of predicting or > controlling. To constrain this diversity in a useful way in the > context of NOTIFY messages within the SIP protocol, we have > historically use event packages, and found this approach to work quite > well. Going forward, in the context of INFO messages within the SIP > protocol, we will use INFO packages for the same reasons. > > Cheers, > Linyi > > -----Original Message----- > From: sipcore-bounces(a)ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf > Of Dean Willis > Sent: Wednesday, September 23, 2009 2:40 AM > To: tianlinyi 34932 > Cc: 'Sanjay Sinha (sanjsinh)'; sipcore(a)ietf.org > Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package > > > On Sep 22, 2009, at 10:26 AM, tianlinyi 34932 wrote: > >> Hi, Paul >> >> As i said there is specification clearly states the usage of Content >> type and a registration with this Content Type will be provided. The >> specification will also mention how it will be used in SIP INFO, why >> it is still un-specified? >> >> For example, if 3GPP defines the content type and its usage with SIP >> INFO in a specification why INFO package hearder should be used? I >> didn't see any IOP problem on this approach. >> > > > If 3GPP were to define a new MIME type that is only used in SIP INFO > messages, then you are correct in that the INFO package framework > would add little value. > > However, this is not how MIME types work. > > The MIME type model defines only "what an object is", not "how the > object can be used". To negotiate around "how the object will be used > in this application", we need a higher-level of specification and > negotiation. IN SIP INFO messages, the INFO package definition > provides that level of specification and negotiation. > > The MIME registration process doesn't register things like "This MIME > type can only be used in a SIP INFO message in accordance with the > foobar application as documented in 3GPP TS 99.411." And if somebody > tried to register such a restricted MIME type, I'd hope the ietf-types > people would say "no." Of course, there's no guarantee that no > broken types are going to be registered (especially in vendor trees), > but certainly the majority of existing types aren't broken like this. > Once a type is defined, objects os that type can br transported in > email, HTTP requests, SIP INFO, NOTIFY, and other requests messages, > stored in Windows registries, and so on, in countless application > scenarios that the MIME type registration has no way of predicting or > controlling. To constrain this diversity in a useful way in the > context of NOTIFY messages within the SIP protocol, we have > historically use event packages, and found this approach to work quite > well. Going forward, in the context of INFO messages within the SIP > protocol, we will use INFO packages for the same reasons. > > -- > Dean > > _______________________________________________ > sipcore mailing list > sipcore(a)ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore(a)ietf.org > https://www.ietf.org/mailman/listinfo/sipcore

2 1

Registration of media types application/dssc+xml and application/dssc+der (Update)
by Thomas Kunz 20 Aug '09

20 Aug '09

Hello, I would like to register the two MIME-Types "application/dssc+xml" and "application/dssc+der" as part of our internet draft "draft-ietf-ltans-dssc-10.txt". Can you please review the registration. Thanks, Thomas ====================================================== Type name: application Subtype name: dssc+xml Required parameters: none Optional parameters: "charset" as specified for "application/xml" in RFC 3023. Encoding considerations: Same as specified for "application/xml" in RFC 3023. Security considerations: Same as specified for "application/xml" in Section 10 of RFC 3023. Further security consideration can be found in section 7 of draft-ietf-ltans-dssc-10.txt. Interoperability considerations: Same as specified for "application/xml" in RFC 3023. Published specification: draft-ietf-ltans-dssc-10.txt Applications which use this media: applications for long-term archiving of signed data, applications for signing data / verifying signed data, applications for encrypting / decrypting data Additional information : 1. Magic number(s) : none 2. File extension(s) : .xdssc 3. Macintosh file type code : "TEXT" 4. Object Identifiers: none Person to contact for further information: Thomas Kunz (thomas.kunz(a)sit.fraunhofer.de) Intended usage: COMMON Restrictions on usage: none Author/Change controller: The IETF ====================================================== Type name: application Subtype name: dssc+der Required parameters: none Optional parameters: none Encoding considerations: none for 8-bit transports and in general Base64 for 7-bit transports. Security considerations: Security consideration can be found in section 7 of draft-ietf-ltans-dssc-10.txt. Interoperability considerations: none Published specification: draft-ietf-ltans-dssc-10.txt Applications which use this media: applications for long-term archiving of signed data, applications for signing data / verifying signed data, applications for encrypting / decrypting data Additional information : 1. Magic number(s) : none 2. File extension(s) : .dssc 3. Macintosh file type code : none 4. Object Identifiers: none Person to contact for further information: Thomas Kunz (thomas.kunz(a)sit.fraunhofer.de) Intended usage: COMMON Restrictions on usage: none Author/Change controller: The IETF ======================================================

2 2

IMS Common Cartridge (CC) Mime-type Registration Preliminary Review Request
by Colin Smythe 16 Aug '09

16 Aug '09

Hi, We wish to register a new Mime-type for the IMS Global Learning Consortium's Common Cartridge. As part of that process we submit this application for preliminary peer review. Inserted is the Registration Form. The IMS's Common Cartridge specification, to which this application refers, is available at: http://www.imsglobal.org/cc/index.html. -------------------------------------- Name : Colin Smythe Email : csmythe(a)imsglobal.org MIME media type name : Application MIME subtype name : Standards Tree -imsccml+xml Required parameters : There are no required parameters. Optional parameters : 'charset' The charset parameter of application/imsccml+xml is handled in the same fashion as for application/xml, as specified in Section 3.2 of [RFC3023]. However, per conformance of IMS Global Learning Consortium's Common Cartridge, valid Common Cartridge manifest documents MUST be in the UTF-8 character set. If the charset parameter is present, it MUST take the value "utf-8". Common Cartridge 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 : 8bit This media type may require encoding on transports not capable of handling 8 bit text. Security considerations : Several features of Common Cartridge manifest require dereferencing arbitrary URIs. Implementers are advised to heed the security issues of [RFC3986] Section 7. Common Cartridge describes how learning content can be accessed. A simple Digital Rights Management mechanism is defined through a Web Services based authorization protocol which a Common Cartridge instance may include. All systems supporting the use of Common Cartridges must implement the authorization mechanism. The specification does not constrain how any dynamic content may behave. Therefore, systems must implement access controls that limit the access of any content to system resources. Interoperability considerations : Interoperability is achieved through the use of the 'imsmanifest.xml' which has an associated XSD. The interoperability considerations in Section 3.1 of [RFC3023] also apply to Common Cartridge manifest documents. Common Cartridge manifest documents contain XML elements defined by each specific format, all of which are published specifications. The Common Cartridge XSD which profiles the Content Packaging v1.2 schema and the schemas which profile Common Cartridge usage of IEEE Learning Object Metadata v1.0 and IMS GLC Question Test Interoperability (QTI) v1.2.1 have been defined using the IMS GLC SchemaProf tool v1.0. The tool produces a set of derived schemas, corresponding to the Common Cartridge schema and its profiled auxiliary schemas, against which any cartridge must validate. SchemaProf also allows the application of additional constraints which further constrain how Common Cartridge may be used. These encompass: (a) Static constraints - the parameters (e.g. file names) are fixed in the profile; (b) Dynamic constraints - the parameters are taken from an instance document in the package e.g. the href of a resource must point to a QTI file; (c) Conditional constraints - the constraint depends on a condition. To be deemed to comply with the Common Cartridge specification, cartridges must: (a) Successfully validate against the Common Cartridge schema set; (b) Satisfy all of the additional constraints. Published specification : This media type registration is for the IMS Global Learning Consortium Common Cartridge specification available at http://www.imsglobal.org/cc/index.html. This specification was published in October 2008 after formal approval by the IMS GLC Technical Advisory Board. The mission of IMS GLC is to create standards for the development and adoption of technologies that enable high-quality, accessible, and affordable learning experiences. IMS GLC is now enabling the next generation of Digital Learning Services, combining new forms of digital content, assessment, applications, and administrative services. IMS GLC is supported by over 135 organizations â¤" the worldâ¤s leaders in educational and learning technology, including leading learning technology product suppliers and publishers, leading institutions of learning and training, and leading government and professional consortia. The breakdown of members is 58% leading corporations, 24% leading institutions of learning or school districts, and 18% consortia and/or government organizations. Currently, 47% of member organizations are headquartered outside the United States. IMS GLC has approved and published some 20 standards that are the most widely used learning technology standards in the world. Widely-used IMS GLC standards include meta-data, content packaging, common cartridge, enterprise services, question and test, sequencing, competencies, access for all, ePortfolio, learner information, tools interoperability, resource list, sharable state persistence, vocabulary definition, and learning design. These standards have been used widely in higher education, K-12 education, and corporate training in regions around the globe. All IMS GLC standards are available free of charge via the IMS GLC web site and can be used without royalty. Applications which use this media : The Common Cartridge defines an open format for the distribution of rich, web-based content. It is designed to ensure the correct installation and operation of content across any Common Cartridge conformant platforms and tools. The specification defines a profile for the use of the following specifications which are (in the versions adopted here), already widely implemented and in use across the community: (a) IEEE LOM encompassing; (b) IMS GLC Content Packaging v1.2; (c) IMS GLC Question and Test Interoperability v1.2.1; (d) IMS GLC Authorization Web Service v1.0. The LOM, Content Packaging and Question and Test Interoperability specifications have each been profiled to simplify their use. Thus their scope has been constrained to those features commonly implemented and in use by the community. Experience suggests that interoperability problems that have arisen with implementations of these specifications are frequently the result of differing interpretations of the specs and options being taken that lead to divergence in behavior. A key goal of the Common Cartridge specification therefore has been to provide a tighter definition of their use thus eliminating this divergence. The resulting profile also lends itself to more effective conformance testing of implementations. Additional features offered by the Common Cartridge include: (a) A new resource type for initiating discussion forum interactions; (b) Inclusion of a question bank (i.e., a QTI objectbank), offering tutors additional questions to those contained within the pre-configured assessments, which they can configure around the core material; (c) Optional authorization to protect either the whole cartridge, or selected cartridge resources; (d) The present versions of the specifications supported under Common Cartridge have been selected to offer existing implementations a low barrier to adoption of the Common Cartridge. It is to be anticipated that as new versions of these specifications achieve widespread adoption, they in turn will be adopted thus further enhancing the features supported in future versions of the Common Cartridge. Only platforms which meet the conformance requirements identified in the CC specification and fully implement the CC Authorization service can claim CC compliance. Additional information : 1. Magic number(s) : There is no always present single initial octet sequence. 2. File extension(s) : The CC manifest file must have the name 'imsmanifest.xml'. 3. Macintosh file type code : TEXT 4. Object Identifiers: Not applicable. Other Information : The conceptual model of the Common Cartridge is similar to "cartridge-like" features found in existing commercial vendor solutions, several of the features of the Common Cartridge are included. Conceptually, a Common Cartridge is a package of content and meta-data that is integrated into an LMS learning context. At a high level, this may directly correspond to the notion of "course" in the target LMS. There is no guarantee of the cardinality of the relationship from "learning context" to "Common Cartridge", i.e., the LMS may enforce an arbitrary 1-1 relationship. The data contained in the package breaks down into the following categories: (a) "Learner Experience" Data. These are the resources presented directly to the learner, i.e. content resources; (b) Supplemental Resources. These are resources that may be optionally integrated into the learning context by an instructor or other facilitator e.g. question bank; (c) Operational Data. Data used to control behavioral aspects of the LMS display/interaction with the cartridge e.g. authorization; (d) Descriptive Meta-data. This is the defined IEEE LOM data, and is represented via existing bindings. A Common Cartridge is an IMS GLC Content Package conforming to the following basic structure: (a) A Common Cartridge may define a single organization, or include no organization. Multiple organizations are not permitted and the default attribute for organizations is not therefore supported. The single organization is used on import to integrate with the learning context, and defines the basic navigation structure for the package. The organization assumes the predefined "hierarchical" structure; (b) Only "Learner Experience" resources may be included in the 'organization' hierarchy; (c) Operational data (authorization, cartridge-level meta-data) are defined via discrete resource types within the package; (d) Supplemental resources must not appear in the organization. The LMS provides a way for the instructor/facilitator to inspect/deploy/utilize these resources as they see fit; (e) Common Cartridge resources must be identified with GUIDs, in order to facilitate proper integration in systems that execute "by reference" content usage. Person to contact for further information : 1. Name : Colin Smythe 2. Email : csmythe(a)imsglobal.org Intended usage : Common There are no further comments. Author/Change controller : The Editor for the IMS GLC Common Cartridge specification was Kevin Riley (kriley(a)imsglobal.org) Revisions of the specification are underway but these will be backwards compatible and will always require the presence of the manifest document which is the subject of this registration. ---------------------------------- This is our first attempt at such a registration so please forgive any obvious errors on our part. Thanx. Colin S. -- ------------------------------------------------------------------------------------------------------------ IMS Global Learning Consortium * Innovation * Adoption * Learning ------------------------------------------------------------------------------------------------------------ Colin Smythe Chief Architect IMS Global Learning Consortium Inc. Tel: +44-(0)114-2334009 Fax: +44-(0)114-2334009 Mobile: +44-(0)793-2636911 SkypeName: dunelmcolins SkypeIn(UK): +44(0)20-7193-5892 SkypeIn(USA): +00-1-978-631-0548 Email: csmythe(a)imsglobal.org Web: http://www.imsglobal.org

1 0

Re: application/pkix-attr-cert
by Russ Housley 11 Aug '09

11 Aug '09

Bjoern: >* Russ Housley wrote: > >I suggest that we need a MIME type for attribute certificates that is > >similar to the one already defined for public key certificates > >(application/pkix-cert) and CRLs (application/pkix-crl). > >(I take it this is draft-ietf-pkix-attr-cert-mime-type-00.txt). > > > To: ietf-types(a)iana.org > > Subject: Registration of MIME media type application/pkix-attr-cert > > > > MIME media type name: application > > > > MIME subtype name: pkix-attr-cert > > > > Required parameters: None > > > > Optional parameters: version (default value is "1") > >This needs a definition for the non-default values (syntax, semantics, >perhaps implementation considerations, e.g., for unsupported versions). I'm tempted to drop this. The types defined in RFC 2585 use this construction, and we have never needed it. Is there another type that does this and has good text to steal? > > Encoding considerations: will be none for 8-bit transports and most > > likely Base64 for SMTP or other 7-bit transports > >This needs to be one of the values defined in RFC 4288. I'll do some homework. > > Security considerations: Carries an attribute certificate > >In the draft, a pointer to the security considerations section of the >draft should probably be included here. Will do. > > Interoperability considerations: None > > > > Published specification: RFC 3281 > > > > Applications which use this media type: Any MIME-complaint transport > >This could be more specific. One or two additional sentences as to the >nature of "attribute certificates" would be useful. Also note that the >Abstract should have at least three lines. Will do. > > Additional information: > > Magic number(s): None > > File extension(s): .AC > > Macintosh File Type Code(s): none > > > > Person & email address to contact for further information: > > Russ Housley <housley(a)vigilsec.com> > > > > Intended usage: COMMON > > > > Author/Change controller: > > Russ Housley <housley(a)vigilsec.com> > >I believe the change controller needs to be a standards organisation; >I believe the preference for RFC-defined types is "The IESG". No problem. Thanks for the prompt feedback. Russ

1 0

application/pkix-attr-cert
by Russ Housley 11 Aug '09

11 Aug '09

I suggest that we need a MIME type for attribute certificates that is similar to the one already defined for public key certificates (application/pkix-cert) and CRLs (application/pkix-crl). To: ietf-types(a)iana.org Subject: Registration of MIME media type application/pkix-attr-cert MIME media type name: application MIME subtype name: pkix-attr-cert Required parameters: None Optional parameters: version (default value is "1") Encoding considerations: will be none for 8-bit transports and most likely Base64 for SMTP or other 7-bit transports Security considerations: Carries an attribute certificate Interoperability considerations: None Published specification: RFC 3281 Applications which use this media type: Any MIME-complaint transport Additional information: Magic number(s): None File extension(s): .AC Macintosh File Type Code(s): none Person & email address to contact for further information: Russ Housley <housley(a)vigilsec.com> Intended usage: COMMON Author/Change controller: Russ Housley <housley(a)vigilsec.com>

2 1

Registration of media types application/dssc+xml and application/dssc+der
by Thomas Kunz 05 Aug '09

05 Aug '09

Hello, I would like to register the two MIME-Types "application/dssc+xml" and "application/dssc+der" as part of our internet draft "draft-ietf-ltans-dssc-10.txt". Can you please review the registration. Thanks, Thomas ====================================================== Type name: application Subtype name: dssc+xml Required parameters: none Optional parameters: "charset" the parameter has identical semantics to the charset parameter of the "application/xml" media type as specified in RFC 3023. Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023. Security considerations: Same as general security considerations for application/xml as specified in section 10 of RFC 3023. Further security consideration can be found in section 7 of draft-ietf-ltans-dssc-10.txt. Interoperability considerations: Same as Interoperability considerations as specified in section 3.1 of RFC 3023. Published specification: draft-ietf-ltans-dssc-10.txt Applications which use this media: applications for long-term archiving of signed data, applications for signing data / verifying signed data, applications for encrypting / decrypting data Additional information : 1. Magic number(s) : none 2. File extension(s) : none 3. Macintosh file type code : none 4. Object Identifiers: none Person to contact for further information: Thomas Kunz (thomas.kunz(a)sit.fraunhofer.de) Intended usage: COMMON Restrictions on usage: none Author/Change controller: Thomas Kunz (thomas.kunz(a)sit.fraunhofer.de) ====================================================== Type name: application Subtype name: dssc+der Required parameters: none Optional parameters: none Encoding considerations: This media type must be DER encoded. Security considerations: Security consideration can be found in section 7 of draft-ietf-ltans-dssc-10.txt. Interoperability considerations: none Published specification: draft-ietf-ltans-dssc-10.txt Applications which use this media: applications for long-term archiving of signed data, applications for signing data / verifying signed data, applications for encrypting / decrypting data Additional information : 1. Magic number(s) : none 2. File extension(s) : none 3. Macintosh file type code : none 4. Object Identifiers: none Person to contact for further information: Thomas Kunz (thomas.kunz(a)sit.fraunhofer.de) Intended usage: COMMON Restrictions on usage: none Author/Change controller: Thomas Kunz (thomas.kunz(a)sit.fraunhofer.de) ======================================================

1 0

Registration of media type application/vnd.apple.mpegURL
by Roger Pantos 24 Jul '09

24 Jul '09

Hello there. I'm planning to submit this registration to IANA soon, but per RFC 4288 I'm sending it here first to solicit initial feedback. Thanks. Type name: application Subtype name: vnd.apple.mpegURL Required parameters: (none) Optional parameters: (none) Encoding considerations: Encoded as text, either ASCII or UTF-8. UTF-8 is recommended. Security considerations: - As with any text format, parsers must guard against buffer overflow attacks - Active content: - Several elements of this format are URIs, which clients will use to make network requests of arbitrary entities - Clients should range-check responses to prevent buffer overflows - Clients should load resources identified by URI lazily (specified by protocol) to reduce server DoS - See also Security Considerations in RFC 3986 - Privacy: - URIs are typically http. Implementations may send cookie data with http requests, which could include user data. - Implementations must follow cookie restriction & expiry rules specified by RFC 2965. - Compression: this media type does not employ compression. - The format includes the specification of encryption keys, by URI. The delivery of these keys should be secure, but it is up to the distributor of the media to ensure that it is, e.g. by using HTTP over TLS in conjunction with a secure realm or a session cookie. Interoperability considerations: - No byte-ordering issues, since files are encoded as ASCII or UTF-8 text - Applications may encounter unrecognized tags. These should be ignored. Published specification: http://tools.ietf.org/html/draft-pantos-http-live-streaming Applications that use this media type: - iPhone media player (OS 3.0) - QuickTime Player in Mac OS X (Snow Leopard) Additional information: Magic number(s): #EXTM3U File extension(s): m3u, m3u8 Macintosh file type code(s): none Person & email address to contact for further information: David Singer, singer@.apple.com Intended usage: LIMITED USE Restrictions on usage: (none) Author: Roger Pantos Change controller: David Singer Roger.

2 2

please review "text/rif+xml" media type registration
by Sandro Hawke 21 Jul '09

21 Jul '09

The following media type registration has been recently published as part of a W3C Last Call Working Draft [1], and will soon be submitted to the IESG for review, approval, and registration with IANA (as per [2]). An earlier version of this registration was posted here for review about a year ago [3]. The changes made since then reflect changes in the organization of the RIF family of dialects; there were no changes suggested by reviewers of that posting. At this point, we would appreciate comments on this registration information. If you see any problems, please let us know; I'll act as a liason between these IETF lists and the W3C Working Group responsible for these specifications. -- Sandro [1] http://www.w3.org/TR/rif-core/#Appendix:_RIF_Media_Type_Registration [2] http://www.w3.org/2002/06/registering-mediatype [3] http://lists.w3.org/Archives/Public/www-archive/2008Sep/0023.html ================================================================ Type name: application Subtype name: rif+xml Required parameters: none Optional parameters: charset, as per RFC 3023 (XML Media Types) Encoding considerations: same as RFC 3023 (XML Media Types) Security considerations: Systems which consume RIF documents are potentially vulnerable to attack by malicious producers of RIF documents. The vulnerabilities and forms of attack are similar to those of other Web-based formats with programming or scripting capabilities, such as HTML with embedded Javascript. Excessive Resource Use / Denial of Service Attacks Complete processing of a RIF document, even a conformant RIF Core document, may require arbitrarily great CPU and memory resources. Through the use of "import", processing may also require arbitrary URI dereferencing, which may consume all available network resources on the consuming system or other systems. RIF consuming systems SHOULD implement reasonable defenses against these attacks. Exploiting Implementation Flaws RIF is a relatively complex format, and rule engines can be extremely sophisticated, so it is likely that some RIF consuming systems will have bugs which allow specially constructed RIF documents to perform inappropriate operations. We urge RIF implementors to make systems which carefully anticipate and handle all possible inputs, including those which present syntactic or semantic errors. External (Application) Functions Because RIF may be extended with local, application defined datatypes and functions, new vulnerabilities may be introduced. Before being installed on systems which consume untrusted RIF documents, these external functions should be closely reviewed for their own vulnerabilities and for the vulnerabilities that may occur when they are used in unexpected combinations, like "cross-site scripting" attacks. In addition, as this media type uses the "+xml" convention, it shares the same security considerations as other XML formats; see RFC 3023 (XML Media Types). Interoperability considerations: This media type is intended to be shared with other RIF dialects, to be specified in the future. Interoperation between the dialects is governed by the RIF specifications. Published specifications: RIF Core Dialect W3C Working Draft (Recommendation Track) http://www.w3.org/TR/rif-core/ RIF Datatypes and Builtins W3C Working Draft (Recommendation Track) http://www.w3.org/TR/rif-dtb/ RIF Basic Logic Dialect W3C Working Draft (Recommendation Track) http://www.w3.org/TR/rif-bld/ RIF Production Rule Dialect W3C Working Draft (Recommendation Track) http://www.w3.org/TR/rif-prd/ RIF Framework for Logic Dialects W3C Working Draft (Recommendation Track) http://www.w3.org/TR/rif-fld/ This media type is intended for use by all RIF dialects, including those to be specified in the future. Identification of the RIF dialect in use by a document is done by examining the use of specific XML elements within the document. Applications that use this media type: Unknown at the time of these drafts. Multiple applications are expected, however, before the specification reaches W3C Proposed Recommendation status. Additional information: Magic number(s): As with XML in general (See RFC 3023 (XML Media Types)), there is no magic number for this format. However, the XML namespace "http://www.w3.org/2007/rif#" will normally be present in the document. It may theoretically be missing if the document uses XML entities in an obfuscatory manner. The hex form of that namespace will depend on the charset. For utf-8, the hex is: 68 74 74 70 3a 2f 2f 77 77 77 2e 77 33 2e 6f 72. File extension(s): .rif (or .xml) Macintosh file type code(s): "TEXT" (like other XML) Person & email address to contact for further information: Sandro Hawke, sandro(a)w3.org. Please send technical comments and questions about RIF to public-rif-comments(a)w3.org, a mailing list with a public archive at http://lists.w3.org/Archives/Public/public-rif-comments/ Intended usage: COMMON Restrictions on usage: None Author: The editor and contact for this media type registration is Sandro Hawke, sandro(a)w3.org. Change controller: RIF is a product of the Rule Interchange Format (RIF) Working Group of the World Wide Web Consortium (W3C). See http://www.w3.org/2005/rules/wg for information on the group. The W3C (currently acting through this working group) has change control over the RIF specification.

1 0

Registration of media type application/ipfix in draft-ietf-ipfix-file
by Brian Trammell 17 Jul '09

17 Jul '09

Greetings, Submitted for feedback, the following media type registration appears in draft-ietf-ipfix-file, currently in IESG processing. Thanks, Brian Type name: application Subtype name: ipfix Required parameters: none Optional parameters: none Encoding considerations: IPFIX files are binary, and therefore must be encoded in non-binary contexts. Security considerations: See the Security Considerations section (Section 12) of this document, and the Security Considerations section of [RFC5101]. Interoperability considerations: See the Detailed Specification section (Section 7) of this document. The format is designed to be broadly interoperable, as any valid stream of IPFIX Messages over any transport specified in [RFC5101] MUST be recognizable as a valid IPFIX File. Published specification: This document, especially Section 7, and [RFC5101]. Applications that use this media type: Various IPFIX implementations (see [RFC5153]) support the construction of IPFIX File Readers and Writers. Additional information: none Magic number(s): None, although the first two bytes of any IPFIX file are the first two bytes of a message header, the Version field, which as of [RFC5101] are always 10 in network byte order: 0x00, 0x0A. File extension(s): .ipfix Macintosh file type code(s): none For further information: Authors of this document, IETF IPFIX Working Group Intended usage: LIMITED USE Restrictions on usage: none Change controller: Authors of this document, IETF IPFIX Working Group

1 0