- From: Liam Quin <liam@w3.org>
- Date: Thu, 8 Sep 2005 12:49:37 -0400
- To: ietf-types@iana.org
- Cc: ietf-xml-mime@imc.org, public-qt-comments@w3.org
[
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@Sun.COM>.
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/
Received on Thursday, 8 September 2005 16:50:23 UTC