Liam,
The "Published specification" section of the template should include a
pointer (a URL is OK) to the published specification that describes the
media type.
-Scott-
> -----Original Message-----
> From: Liam Quin [mailto:liam@xxxxxx]
> Sent: Thursday, September 08, 2005 12:50 PM
> To: ietf-types@xxxxxxxx
> Cc: ietf-xml-mime@xxxxxxx; public-qt-comments@xxxxxx
> Subject: W3C Last Call and Media Type request for comments: XSLT 2.0
>
> [
> Notes:
>
> We slipped up in not sending this along with the Last Call
> announcement; please caaept our apologies.
>
> We are using bugzilla to track comments on this document;
> comments on the MIME-related part of the document may be made
> on the ietf-types mailing list or in Bugzilla. See the
> "Status of this Document" section for further information.
>
> We are following
>
> http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-05.txt
> here, and the text is written to be part of a larger document.
>
> Finally, as for XQuery, we'll probably expand the Security
> Considerations after gaining more implementation experience.
>
> ]
>
>
> Registration of MIME Media Type application/xslt+xml
> ----------------------------------------------------
>
> MIME media type name: application
> MIME subtype name: xslt+xml
> Required parameters: None.
> Optional parameters: charset
> This parameter has identical semantics to the charset parameter
> of the application/xml media type as specified in [RFC3023].
>
> Encoding considerations:
> By virtue of XSLT content being XML, it has the same
> considerations
> when sent as "application/xslt+xml" as does XML. See RFC 3023,
> section 3.2.
>
> Security considerations:
> Several XSLT instructions may cause arbitrary URIs to be
> dereferenced. In this case, the security issues of [RFC3986],
> section 7, should be considered.
>
> In addition, because of the extensibility features for XSLT, it is
> possible that "application/xslt+xml" may describe content that has
> security implications beyond those described here. However, if the
> processor follows only the normative semantics of this
> specification,
> this content will be ignored. Only in the case where the processor
> recognizes and processes the additional content, or where further
> processing of that content is dispatched to other
> processors, would
> security issues potentially arise. And in that case, they
> would fall
> outside the domain of this registration document.
>
> Interoperability considerations:
>
> This specification describes processing semantics that dictate
> behavior that must be followed when dealing with, among
> other things,
> unrecognized elements.
>
> Because XSLT is extensible, conformant "application/xslt+xml"
> processors can expect that content received is well-formed XML,
> but it cannot be guaranteed that the content is valid XSLT or that
> the processor will recognize all of the elements and attributes in
> the document.
>
> Published specification:
>
> This media type registration is for XSLT stylesheet modules as
> described by this specification. It is also appropriate
> to use this
> media type with earlier and later versions of the XSLT language.
>
> Applications which use this media type:
>
> Existing XSLT 1.0 stylesheets are most often described using the
> unregistered media type "text/xsl".
>
> There is no experimental, vendor specific, or personal tree
> predecessor to "application/xslt+xml", reflecting the fact that
> no applications currently recognize it. This new type is being
> registered in order to allow for the expected deployment of XSLT
> 2.0 on the World Wide Web, as a first class XML application.
>
> Additional information:
>
> Magic number(s):
>
> There is no single initial octet sequence that is
> always present
> in XSLT documents.
>
> File extension(s):
>
> XSLT documents are most often identified with the extensions
> ".xsl" or ".xslt".
>
> Macintosh File Type Code(s):
>
> TEXT
>
> Person & email address to contact for further information:
>
> Norman Walsh, <Norman.Walsh@xxxxxxx>.
>
> Intended usage:
>
> COMMON
>
> Author/Change controller:
>
> The XSLT specification is a work product of the World Wide Web
> Consortium's XSL Working Group. The W3C has change control over
> these specifications.
>
> B.2 Fragment Identifiers
>
> For documents labeled as "application/xslt+xml", the
> fragment identifier
> notation is exactly that for "application/xml", as
> specified in RFC 3023.
>
> --
> Liam Quin, W3C XML Activity Lead, http://www.w3.org/People/Quin/
> http://www.holoweb.net/~liam/
>
|
