RE: W3C Last Call and Media Type request for comments: XSLT 2.0

"Scott Hollenbeck" <sah@428cobrajet.net> Thu, 08 September 2005 16:55 UTC

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j88Gt4ja041008; Thu, 8 Sep 2005 09:55:04 -0700 (PDT) (envelope-from owner-ietf-xml-mime@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j88Gt4ef041007; Thu, 8 Sep 2005 09:55:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f
Received: from mail.verisignlabs.com (cliffie.verisignlabs.com [65.201.175.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j88Gt3Yc040999 for <ietf-xml-mime@imc.org>; Thu, 8 Sep 2005 09:55:03 -0700 (PDT) (envelope-from sah@428cobrajet.net)
Received: from dul1shollenbl1 ([::ffff:216.168.239.87]) (AUTH: LOGIN shollenb, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Thu, 08 Sep 2005 12:55:02 -0400 id 003682A1.43206CE6.00000288
From: Scott Hollenbeck <sah@428cobrajet.net>
To: 'Liam Quin' <liam@w3.org>, ietf-types@iana.org
Cc: ietf-xml-mime@imc.org, public-qt-comments@w3.org
Subject: RE: W3C Last Call and Media Type request for comments: XSLT 2.0
Date: Thu, 08 Sep 2005 12:54:46 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <20050908164936.GN20337@w3.org>
Thread-Index: AcW0lVigqnlQuQ1tSGOD0uN8+LBeKwAAFnmg
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Message-ID: <courier.43206CE6.00000288@mail.verisignlabs.com>
Sender: owner-ietf-xml-mime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-xml-mime/mail-archive/>
List-ID: <ietf-xml-mime.imc.org>
List-Unsubscribe: <mailto:ietf-xml-mime-request@imc.org?body=unsubscribe>

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@w3.org] 
> Sent: Thursday, September 08, 2005 12:50 PM
> To: ietf-types@iana.org
> Cc: ietf-xml-mime@imc.org; public-qt-comments@w3.org
> 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@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/
>