August 2009 - Ietf-types

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