Subject: MIME media types in RFC 4047
From: ned.freed at mrochek.com ([email-masked])
Date: Tue Jan 3 16:22:59 2006

> We have been informed that RFC 4047 is published.

> RFC 4047 defines two new top-level MIME media types:
> image/fits
> application/fits

> The IANA web pages
> http://www.iana.org/assignments/media-types/application/
> http://www.iana.org/assignments/media-types/image/
> have not been updated to indicate that publication
> has occurred.

> Do the authors of the RFC need to make any further explicit request to
> the IANA, or should we simply await the next update?

The update is supposed to be done automatically, and in theory it is supposed
to happen before the RFC comes out.

I suggest pinging IANA to find out why the update hasn't occurred.

				Ned

From: blilly at erols.com (Bruce Lilly)
Date: Tue Jan  3 16:22:59 2006
Subject: regarding your comments on proposed media type text/troff' to Informational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Thu April 21 2005 08:43, Bruce Lilly wrote:

> I believe that the issues can be dealt with by revision to the parameter
> definition; I'll propose some specific text later today.

OLD text:

     process: Lists a recommended command pipeline for formatting.  The
        parameter value may need to be quoted or encoded as provided
        for by [N4.RFC2045] as amended by [N5.RFC2231] and [N6.Errata].

NEW text:

     process: Human-readable additional information for formatting,
        including environment variables, preprocessor arguments and
        order, formatter arguments, and postprocessors.  The parameter
        value may need to be quoted or encoded as provided for by
        [N4.RFC2045] as amended by [N5.RFC2231] and [N6.Errata].
        Implementations SHOULD NOT attempt any execution or other
        interpretation of the parameter value, as the parameter value
        may be prose text.  Implementations SHOULD present the
        parameter (after reassembly of continuation parameters, etc.)
        as information related to the media type, particularly if the
        media content is not immediately available (e.g. as with
        message/external-body composite media [N3.RFC2046]).

From: blilly at erols.com (Bruce Lilly)
Date: Tue Jan  3 16:22:59 2006
Subject: regarding your comments on proposed media type text/troff' to Informational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Thu April 21 2005 08:43, Bruce Lilly wrote:

> I believe that the issues can be dealt with by revision to the parameter
> definition; I'll propose some specific text later today.

OLD text:

     process: Lists a recommended command pipeline for formatting.  The
        parameter value may need to be quoted or encoded as provided
        for by [N4.RFC2045] as amended by [N5.RFC2231] and [N6.Errata].

NEW text:

     process: Human-readable additional information for formatting,
        including environment variables, preprocessor arguments and
        order, formatter arguments, and postprocessors.  The parameter
        value may need to be quoted or encoded as provided for by
        [N4.RFC2045] as amended by [N5.RFC2231] and [N6.Errata].
        Implementations SHOULD NOT attempt any execution or other
        interpretation of the parameter value, as the parameter value
        may be prose text.  Implementations SHOULD present the
        parameter (after reassembly of continuation parameters, etc.)
        as information related to the media type, particularly if the
        media content is not immediately available (e.g. as with
        message/external-body composite media [N3.RFC2046]).

From: blilly at erols.com (Bruce Lilly)
Date: Thu Apr 21 14:43:32 2005
Subject: regarding your comments on proposed media type text/troff' to Informational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wed April 20 2005 15:24, Tony Hansen wrote:
>  From a process point of view, can we declare consensus on removing the 
> process= parameter?
[...]
> Bruce, would you be willing to declare that the skirmish was lost, but 
> the battle won, and republish the document without the process= parameter?

Removal of the parameter would require additional changes; at minimum
to the security considerations and to the last paragraph of the
registration form.  More important, it would leave no means of content
negotiation (there are some mechanisms which use RFC 2506/2533/2534/2738,
but those mechanisms do not have provision for the sort of information
that needs to be conveyed, and require a separate registration
mechanism which would raise chicken-vs.-egg issues) or for indicating
processing steps in a language-independent manner separate from but
clearly related to the content (which may be sizable and remote) short
of providing truly executable content in a separate file; and that
approach has practical problems (for a start, it lacks a clear
relationship to the specific content) and raises several security
issues.

I can see no mechanism for making substantive revision to the definition
of a subtype's parameters (as opposed to adding commentary -- and that
doesn't seem to work particularly well); adding a parameter at some
later stage, even if possible, would raise issues about versioning of
the media subtype specification (as distinct from version information
regarding the defined content or the applications needed to process
that content). So it seems impractical to rush through a partial subtype
definition now in the hope that it could be fixed later.

I believe that the issues can be dealt with by revision to the parameter
definition; I'll propose some specific text later today.

If a suitable compromise can't be reached, it may be best to simply
withdraw the proposal; the universe has survived for several billion
years without such a subtype definition, and there are current products
which work around the lack of a suitable standards tree definition by
using unregistered, unregisterable types such as application/x-troff.
>From [email-masked]  Thu Apr 21 14:43:12 2005
From: blilly at erols.com (Bruce Lilly)
Date: Thu Apr 21 14:43:36 2005
Subject: regarding your comments on proposed media type text/troff' to
	Informational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wed April 20 2005 15:24, Tony Hansen wrote:
>  From a process point of view, can we declare consensus on removing the 
> process= parameter?
[...]
> Bruce, would you be willing to declare that the skirmish was lost, but 
> the battle won, and republish the document without the process= parameter?

Removal of the parameter would require additional changes; at minimum
to the security considerations and to the last paragraph of the
registration form.  More important, it would leave no means of content
negotiation (there are some mechanisms which use RFC 2506/2533/2534/2738,
but those mechanisms do not have provision for the sort of information
that needs to be conveyed, and require a separate registration
mechanism which would raise chicken-vs.-egg issues) or for indicating
processing steps in a language-independent manner separate from but
clearly related to the content (which may be sizable and remote) short
of providing truly executable content in a separate file; and that
approach has practical problems (for a start, it lacks a clear
relationship to the specific content) and raises several security
issues.

I can see no mechanism for making substantive revision to the definition
of a subtype's parameters (as opposed to adding commentary -- and that
doesn't seem to work particularly well); adding a parameter at some
later stage, even if possible, would raise issues about versioning of
the media subtype specification (as distinct from version information
regarding the defined content or the applications needed to process
that content). So it seems impractical to rush through a partial subtype
definition now in the hope that it could be fixed later.

I believe that the issues can be dealt with by revision to the parameter
definition; I'll propose some specific text later today.

If a suitable compromise can't be reached, it may be best to simply
withdraw the proposal; the universe has survived for several billion
years without such a subtype definition, and there are current products
which work around the lack of a suitable standards tree definition by
using unregistered, unregisterable types such as application/x-troff.
>From [email-masked]  Thu Apr 21 16:34:20 2005
From: blilly at erols.com (Bruce Lilly)
Date: Thu Apr 21 16:34:35 2005
Subject: regarding your comments on proposed media type text/troff' to
	Informational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Thu April 21 2005 08:43, Bruce Lilly wrote:

> I believe that the issues can be dealt with by revision to the parameter
> definition; I'll propose some specific text later today.

OLD text:

     process: Lists a recommended command pipeline for formatting.  The
        parameter value may need to be quoted or encoded as provided
        for by [N4.RFC2045] as amended by [N5.RFC2231] and [N6.Errata].

NEW text:

     process: Human-readable additional information for formatting,
        including environment variables, preprocessor arguments and
        order, formatter arguments, and postprocessors.  The parameter
        value may need to be quoted or encoded as provided for by
        [N4.RFC2045] as amended by [N5.RFC2231] and [N6.Errata].
        Implementations SHOULD NOT attempt any execution or other
        interpretation of the parameter value, as the parameter value
        may be prose text.  Implementations SHOULD present the
        parameter (after reassembly of continuation parameters, etc.)
        as information related to the media type, particularly if the
        media content is not immediately available (e.g. as with
        message/external-body composite media [N3.RFC2046]).
>From [email-masked]  Thu Apr 21 16:34:20 2005
From: blilly at erols.com (Bruce Lilly)
Date: Thu Apr 21 16:34:37 2005
Subject: regarding your comments on proposed media type text/troff' to
	Informational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Thu April 21 2005 08:43, Bruce Lilly wrote:

> I believe that the issues can be dealt with by revision to the parameter
> definition; I'll propose some specific text later today.

OLD text:

     process: Lists a recommended command pipeline for formatting.  The
        parameter value may need to be quoted or encoded as provided
        for by [N4.RFC2045] as amended by [N5.RFC2231] and [N6.Errata].

NEW text:

     process: Human-readable additional information for formatting,
        including environment variables, preprocessor arguments and
        order, formatter arguments, and postprocessors.  The parameter
        value may need to be quoted or encoded as provided for by
        [N4.RFC2045] as amended by [N5.RFC2231] and [N6.Errata].
        Implementations SHOULD NOT attempt any execution or other
        interpretation of the parameter value, as the parameter value
        may be prose text.  Implementations SHOULD present the
        parameter (after reassembly of continuation parameters, etc.)
        as information related to the media type, particularly if the
        media content is not immediately available (e.g. as with
        message/external-body composite media [N3.RFC2046]).
>From [email-masked]  Thu Apr 21 14:33:25 2005
From: mccobb at us.ibm.com (Gerald McCobb)
Date: Fri Apr 22 15:31:40 2005
Subject: Request for comments regarding draft-mccobb-xplusv-media-type-01
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

In response to your previous comments (thanks) I submitted 
draft-mccobb-xplusv-media-type-02.txt to [email-masked].  Please 
review and thanks in advance:

Network Working Group                                          G. McCobb
Internet-Draft                                           IBM Corporation
Expires: Oct. 1, 2005                                      April 1, 2005

                XHTML+Voice - application/xhtml+voice+xml
                    draft-mccobb-xplusv-media-type-02

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance 
   with RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six 
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as 
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved

Abstract

   This document describes the registration of the MIME sub-type
   application/xhtml+voice+xml.  This sub-type is intended for use as a
   media descriptor for XHTML+Voice multimodal language documents.  The
   XHTML+Voice 1.2 language specification is maintained by the VoiceXML
   Forum at <http://www.voicexml.org/specs/multimodal/x+v/12/>.

1.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119
   [RFC2119].

McCobb                   Expires Oct. 1, 2005                   [Page 1]

Internet-Draft   XHTML+Voice - application/xhtml+voice+xml April 1, 2005

2. Introduction

   XHTML+Voice is a member of the XHTML family of document types, as
   specified by XHTML Modularization [XHTMLMOD].  XHTML+Voice extends
   XHTML 1.1 [XHTML11] with a modularized subset of VoiceXML 2.0
   [VXML20], XML Events [XMLEVNTS], and a few extensions to both XHTML
   and VoiceXML 2.0.  XHTML 1.1, VoiceXML 2.0 and XML Events are W3C
   Recommendations.

   The language integration defined by XHTML+Voice supports all modules
   defined by XHTML Modularization, and adds voice interaction to XHTML
   elements to enable multimodal applications.  The defined document
   type for XHTML+Voice is XHTML Host language document type conformant.

   XHTML+Voice 1.2 [XPLUSV12] is maintained by the VoiceXML Forum, at
   URI location <http://www.voicexml.org/specs/multimodal/x+v/12/>.

2.1 application/xhtml+voice+xml Usage

   The application/xhtml+voice+xml media type is intended to be a media
   descriptor for XHTML+Voice multimodal documents. Multimodal browsers
   have special processing requirements for XHTML+Voice documents, such
   as running a voice browser component, and support for the DOM Level
   2 Event Model [DOM2EV] and XML Events [XMLEVNTS].

   This media type registration is not intended for email usage.

3. IANA Registration

      To: [email-masked]
      Subject: Registration of Standard MIME media type 
               application/xhtml+voice+xml

      MIME media type name: application

      MIME subtype name: xhtml+voice+xml

      Required parameters: none

      Optional parameters:

        charset:  has the same semantics as the charset parameter of the
                  "application/xml" media type specified in [RFC3023].

      Encoding considerations: 7bit.  See section 4 of [RFC3236].

      Security considerations:
 
   XHTML+Voice is an extension of XHTML and has the same security issues

McCobb                   Expires Oct. 1, 2005                   [Page 2]

Internet-Draft   XHTML+Voice - application/xhtml+voice+xml April 1, 2005

   as XHTML.  These include interpreting anchors and forms in XHTML
   documents, and scripting languages and other dynamic interactive
   capabilities.  See section 7 of [RFC3236].

   In addition, the scripting language can be accessed by both the XHTML
   and the VoiceXML 2.0 markup embedded in the XHTML+Voice document.
   See section 1.3.1.5 of [XPLUSV12].

      Interoperability considerations :

   Because XHTML+Voice is built upon W3C standard recommendations, it is
   designed to be interoperable across a wide range of platforms and
   client devices.  Because the extensions to XHTML are identified by
   their namespaces, all browsers that have namespace support can run an
   XHTML+Voice document as an XHTML document without voice interaction.
 
     Published specification:

         The latest published version of XHTML+Voice is [XPLUSV12].

      Applications which use this media type:

         XHTML+Voice documents are intended to be deployed on the World
         Wide Web and rendered by multimodal browsers that support the
         visual and voice modes of interaction.  Because XHTML+Voice is
         an application of XML, authors can expect XHTML+Voice user
         agents to be conformant XML 1.0 [XML] processors.  See section
         2 of [RFC3236].

      Additional information:

         Magic number(s):  There is no single string that is always
             present.
         File extension(s): mxml, xhvml, xvml, xvm
         Macintosh File Type Code(s): TEXT

      Person & email address to contact for further information:

         Gerald M. McCobb
         [email-masked]

      Intended usage: COMMON

      Author/Change controller: Gerald McCobb

      Further information:

4. Fragment Identifiers

   See section 3 of [RFC3236].  Following [RFC3236], fragment

McCobb                   Expires Oct. 1, 2005                   [Page 3]

Internet-Draft   XHTML+Voice - application/xhtml+voice+xml April 1, 2005

   identifiers for XHTML+Voice documents designate the element with the
   corresponding ID attribute value (see [XML] section 3.3.1).

   While XHTML+Voice adds new ID attributes with fragment identifier
   namespaces that are not in the same namespace as XHTML, the fragment
   identifiers are processed in the same namespace as the ID attribute's
   namespace.

5. Recognizing XHTML+Voice files

   Because XHTML+Voice is XML, an XHTML+Voice document [optionally]
   starts with an XML declaration which begins with "<?xml" and has a
   DOCTYPE declaration "<!DOCTYPE html".  XHTML+Voice 1.2 has the
   following DOCTYPE declaration:
 
   <!DOCTYPE html PUBLIC "-//VoiceXML Forum//DTD XHTML+Voice 1.2//EN"
"http://www.voicexml.org/specs/multimodal/x+v/12/dtd/xhtml+voice12.dtd">
 
   Because XHTML+Voice is in the XHTML family of languages, the root
   element of an XHTML+Voice document is 'html' and '<html' can be found
   near the top of the document. 

6. Security Considerations

   Security considerations for this media type are discussed in the MIME
   type registration that appears in section 3.

7. Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2396]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifiers (URI): Generic Syntax", RFC 2396,
              August 1998.

   [RFC3023]  Murata, M., St. Laurent, S., and D. Kohn, "XML Media
              Types", RFC 3023, January 2001.

   [RFC3236]  Baker, M., Stark, P., "The 'application/xhtml+xml' Media
              Type", RFC 3236, January 2002.

   [XML]      "Extensible Markup Language (XML) 1.0", W3C
              Recommendation.  Available at <http://www.w3.org/TR/REC-
              xml> (or <http://www.w3.org/TR/2000/REC-xml-20001006>).

   [XHTMLMOD] "Modularization of XHTML," 10 April, 2001, Murray Altheim,
              Frank Boumphrey, Sam Dooley, et al, W3C Recommendation, 
              http://www.w3.org/TR/xhtml-modularization/

McCobb                   Expires Oct. 1, 2005                   [Page 4]

Internet-Draft   XHTML+Voice - application/xhtml+voice+xml April 1, 2005

   [XHTML11]  "XHTML 1.1 - Module-based XHTML," 31 May 2001, Murray 
              Altheim, Shane McCarron, W3C Recommendation,
              http://www.w3.org/TR/xhtml11/.

   [DOM2EV]   "Document Object Model Level 2 Events Specification," 
              Tom Pixley, 2000.  W3C Recommendation,
              http://www.w3.org/TR/DOM-Level-2-Events/.

   [XMLEVNTS] "XML Events - An events syntax for XML", Steven
              Pemberton, T. V. Raman, and Shane McCarron, 2002.  W3C
              Recommendation, http://www.w3.org/TR/xml-events/.
   [XPLUSV12] "XHTML+Voice Profile 1.2," 16 March 2004, J. Axelsson,
              et al, http://www.voicexml.org/specs/multimodal/x+v/12/

   [VXML20]   "Voice Extensible Markup Language (VoiceXML)," 16 March
              2004, Scott McGlashan et al, W3C Recommendation,
              http://www.w3.org/TR/voicexml20/.

8. Authors' Address

   Gerald M. McCobb
   IBM Corporation
   8051 Congress Avenue, Office 2019
   Boca Raton, Florida 33487
   USA

   Phone: +1-561-862-2109
   Fax:   +1-561-862-3922
   EMail: [email-masked]

9. Full Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on 
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 
   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

   Intellectual Property

   The IETF takes no position regarding the validity or scope of any

McCobb                   Expires Oct. 1, 2005                   [Page 5]

Internet-Draft   XHTML+Voice - application/xhtml+voice+xml April 1, 2005

   Intellectual Property Rights or other rights that might be claimed 
   to pertain to the implementation or use of the technology described 
   in this document or the extent to which any license under such 
   rights might or might not be available; nor does it represent that 
   it has made any independent effort to identify any such rights. 
   Information on the procedures with respect to rights in RFC 
   documents can be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use
   of such proprietary rights by implementers or users of this 
   specification can be obtained from the IETF on-line IPR repository 
   at http://www.ietf.org/ipr. 

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   [email-masked].

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Mccobb                   Expires May 15, 2005                   [Page 6]

Regards,
Gerald McCobb
IBM
8051 Congress Avenue
Boca Raton, FL 33487
Tel. # 561-862-2109 T/L 975-2109

Bjoern Hoehrmann <[email-masked]>
03/26/2005 06:06 PM
 
        To:     Gerald McCobb/Boca Raton/IBM@IBMUS
        cc:     [email-masked], [email-masked]
        Subject:        Re: Request for comments regarding 
draft-mccobb-xplusv-media-type-01

* Gerald McCobb wrote:
>2.1 application/xhtml+voice+xml Usage
>
>   The application/xhtml+voice+xml media type is intended to be a media
>   descriptor for XHTML+Voice documents.
>
>   This media type registration is not intended for email usage.

The draft does not really explain why there is a need for such a
type in the first place; why don't you use application/xhtml+xml?

>      Optional parameters:
>   version:  refers to the XHTML+Voice language version in the document.
>             Acceptable values are 1.0, 1.1, and 1.2 (default).

What are the processing requirements for this parameter?

>   charset:  has the same meaning as the text/html media type.  See
>   section 2 of [RFC 2854].

A word seems to be missing here. It is not really clear why the draft
refers to RFC 2854 rather than RFC 3023 or RFC 3236. 

>      Security considerations:
> 
>   XHTML+Voice is an extension of XHTML and has the same security issues
>   as XHTML.  These include interpreting anchors and forms in HTML
>   documents, and scripting languages and other dynamic interactive
>   capabilities.  See section 7 of [RFC 2854].

So the extensions to XHTML have no security considerations?

>         File extension(s): html, htm, mxml, xvml

I don't think .html and .htm should be listed here, they are already in
common use for application/xhtml+xml and text/html.

>4. Fragment Identifiers
>
>   See section 3 of [RFC 2854].

It is unclear what this means, RFC 2854 and RFC 3236 have inconsistent
rules for fragment identifiers and XHTML+Voice adds new ID attributes
so that the fragment identifier namespaces are different.

>6. Security Considerations
>
>   Security considerations for this media type are discussed in the MIME
>   type registration that appears in section 4.

Section 4 has no security considerations...

>7. References

The draft should be clear about which of these references are
informative and which normative.
-- 
Bj?rn H?hrmann ? mailto:[email-masked] ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20050421/e3f4518f/attachment-0001.html
>From [email-masked]  Fri Apr 29 20:26:37 2005
From: sla at ucolick.org (Steve Allen)
Date: Fri Apr 29 20:27:48 2005
Subject: MIME media types in RFC 4047
Message-ID: <[email-masked]>

We have been informed that RFC 4047 is published.

RFC 4047 defines two new top-level MIME media types:
image/fits
application/fits

The IANA web pages
http://www.iana.org/assignments/media-types/application/
http://www.iana.org/assignments/media-types/image/
have not been updated to indicate that publication
has occurred.

Do the authors of the RFC need to make any further explicit request to
the IANA, or should we simply await the next update?

--
Steve Allen          UCO/Lick Observatory       Santa Cruz, CA 95064
[email-masked]      Voice: +1 831 459 3046     http://www.ucolick.org/~sla
PGP: 1024/E46978C5   F6 78 D1 10 62 94 8F 2E    49 89 0E FE 26 B4 14 93
>From [email-masked]  Sat Apr 30 17:52:18 2005
From: ned.freed at mrochek.com ([email-masked])
Date: Sat Apr 30 17:53:26 2005
Subject: MIME media types in RFC 4047
In-Reply-To: "Your message dated Fri, 29 Apr 2005 11:26:37 -0700"
	<[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> We have been informed that RFC 4047 is published.

> RFC 4047 defines two new top-level MIME media types:
> image/fits
> application/fits

> The IANA web pages
> http://www.iana.org/assignments/media-types/application/
> http://www.iana.org/assignments/media-types/image/
> have not been updated to indicate that publication
> has occurred.

> Do the authors of the RFC need to make any further explicit request to
> the IANA, or should we simply await the next update?

The update is supposed to be done automatically, and in theory it is supposed
to happen before the RFC comes out.

I suggest pinging IANA to find out why the update hasn't occurred.

				Ned
>From [email-masked]  Sun Apr  3 08:13:56 2005
From: YakovS at solidmatrix.com (Yakov Shafranovich)
Date: Tue Jan  3 16:22:57 2006
Subject: Type 'text/csv', draft-04
Message-ID: <[email-masked]>

I posted a new version (-04) correcting the ABNF grammar in response to 
IESG comments, adding a few clarifications and adding a new optional 
"header" parameter to indicate the absence or presence of a header line. 
Copies of the draft can be found below and the draft should post to the 
IETF ID repository sometime Monday:

http://www.shaftek.org/publications/drafts/mime-csv/draft-shafranovich-mime-csv-04.html
http://www.shaftek.org/publications/drafts/mime-csv/draft-shafranovich-mime-csv-04.txt

HTML and text diff of changes:

http://www.shaftek.org/publications/drafts/mime-csv/rfcdiff-03-to-04.html
http://www.shaftek.org/publications/drafts/mime-csv/diff-03-to-04.txt

Yakov

From: blilly at erols.com (Bruce Lilly)
Date: Tue Jan  3 16:22:59 2006
Subject: regarding your comments on proposed media type text/troff' to Informational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wed April 20 2005 15:24, Tony Hansen wrote:
>  From a process point of view, can we declare consensus on removing the 
> process= parameter?
[...]
> Bruce, would you be willing to declare that the skirmish was lost, but 
> the battle won, and republish the document without the process= parameter?

Removal of the parameter would require additional changes; at minimum
to the security considerations and to the last paragraph of the
registration form.  More important, it would leave no means of content
negotiation (there are some mechanisms which use RFC 2506/2533/2534/2738,
but those mechanisms do not have provision for the sort of information
that needs to be conveyed, and require a separate registration
mechanism which would raise chicken-vs.-egg issues) or for indicating
processing steps in a language-independent manner separate from but
clearly related to the content (which may be sizable and remote) short
of providing truly executable content in a separate file; and that
approach has practical problems (for a start, it lacks a clear
relationship to the specific content) and raises several security
issues.

I can see no mechanism for making substantive revision to the definition
of a subtype's parameters (as opposed to adding commentary -- and that
doesn't seem to work particularly well); adding a parameter at some
later stage, even if possible, would raise issues about versioning of
the media subtype specification (as distinct from version information
regarding the defined content or the applications needed to process
that content). So it seems impractical to rush through a partial subtype
definition now in the hope that it could be fixed later.

I believe that the issues can be dealt with by revision to the parameter
definition; I'll propose some specific text later today.

If a suitable compromise can't be reached, it may be best to simply
withdraw the proposal; the universe has survived for several billion
years without such a subtype definition, and there are current products
which work around the lack of a suitable standards tree definition by
using unregistered, unregisterable types such as application/x-troff.

From: blilly at erols.com (Bruce Lilly)
Date: Tue Jan  3 16:22:59 2006
Subject: regarding your comments on proposed media type text/troff' to Informational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wed April 20 2005 15:24, Tony Hansen wrote:
>  From a process point of view, can we declare consensus on removing the 
> process= parameter?
[...]
> Bruce, would you be willing to declare that the skirmish was lost, but 
> the battle won, and republish the document without the process= parameter?

Removal of the parameter would require additional changes; at minimum
to the security considerations and to the last paragraph of the
registration form.  More important, it would leave no means of content
negotiation (there are some mechanisms which use RFC 2506/2533/2534/2738,
but those mechanisms do not have provision for the sort of information
that needs to be conveyed, and require a separate registration
mechanism which would raise chicken-vs.-egg issues) or for indicating
processing steps in a language-independent manner separate from but
clearly related to the content (which may be sizable and remote) short
of providing truly executable content in a separate file; and that
approach has practical problems (for a start, it lacks a clear
relationship to the specific content) and raises several security
issues.

I can see no mechanism for making substantive revision to the definition
of a subtype's parameters (as opposed to adding commentary -- and that
doesn't seem to work particularly well); adding a parameter at some
later stage, even if possible, would raise issues about versioning of
the media subtype specification (as distinct from version information
regarding the defined content or the applications needed to process
that content). So it seems impractical to rush through a partial subtype
definition now in the hope that it could be fixed later.

I believe that the issues can be dealt with by revision to the parameter
definition; I'll propose some specific text later today.

If a suitable compromise can't be reached, it may be best to simply
withdraw the proposal; the universe has survived for several billion
years without such a subtype definition, and there are current products
which work around the lack of a suitable standards tree definition by
using unregistered, unregisterable types such as application/x-troff.

From: mccobb at us.ibm.com (Gerald McCobb)
Date: Tue Jan  3 16:22:59 2006
Subject: Request for comments regarding draft-mccobb-xplusv-media-type-01
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

In response to your previous comments (thanks) I submitted 
draft-mccobb-xplusv-media-type-02.txt to [email-masked].  Please 
review and thanks in advance:

Network Working Group                                          G. McCobb
Internet-Draft                                           IBM Corporation
Expires: Oct. 1, 2005                                      April 1, 2005

                XHTML+Voice - application/xhtml+voice+xml
                    draft-mccobb-xplusv-media-type-02

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance 
   with RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six 
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as 
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved

Abstract

   This document describes the registration of the MIME sub-type
   application/xhtml+voice+xml.  This sub-type is intended for use as a
   media descriptor for XHTML+Voice multimodal language documents.  The
   XHTML+Voice 1.2 language specification is maintained by the VoiceXML
   Forum at <http://www.voicexml.org/specs/multimodal/x+v/12/>.

1.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119
   [RFC2119].

McCobb                   Expires Oct. 1, 2005                   [Page 1]

Internet-Draft   XHTML+Voice - application/xhtml+voice+xml April 1, 2005

2. Introduction

   XHTML+Voice is a member of the XHTML family of document types, as
   specified by XHTML Modularization [XHTMLMOD].  XHTML+Voice extends
   XHTML 1.1 [XHTML11] with a modularized subset of VoiceXML 2.0
   [VXML20], XML Events [XMLEVNTS], and a few extensions to both XHTML
   and VoiceXML 2.0.  XHTML 1.1, VoiceXML 2.0 and XML Events are W3C
   Recommendations.

   The language integration defined by XHTML+Voice supports all modules
   defined by XHTML Modularization, and adds voice interaction to XHTML
   elements to enable multimodal applications.  The defined document
   type for XHTML+Voice is XHTML Host language document type conformant.

   XHTML+Voice 1.2 [XPLUSV12] is maintained by the VoiceXML Forum, at
   URI location <http://www.voicexml.org/specs/multimodal/x+v/12/>.

2.1 application/xhtml+voice+xml Usage

   The application/xhtml+voice+xml media type is intended to be a media
   descriptor for XHTML+Voice multimodal documents. Multimodal browsers
   have special processing requirements for XHTML+Voice documents, such
   as running a voice browser component, and support for the DOM Level
   2 Event Model [DOM2EV] and XML Events [XMLEVNTS].

   This media type registration is not intended for email usage.

3. IANA Registration

      To: [email-masked]
      Subject: Registration of Standard MIME media type 
               application/xhtml+voice+xml

      MIME media type name: application

      MIME subtype name: xhtml+voice+xml

      Required parameters: none

      Optional parameters:

        charset:  has the same semantics as the charset parameter of the
                  "application/xml" media type specified in [RFC3023].

      Encoding considerations: 7bit.  See section 4 of [RFC3236].

      Security considerations:
 
   XHTML+Voice is an extension of XHTML and has the same security issues

McCobb                   Expires Oct. 1, 2005                   [Page 2]

Internet-Draft   XHTML+Voice - application/xhtml+voice+xml April 1, 2005

   as XHTML.  These include interpreting anchors and forms in XHTML
   documents, and scripting languages and other dynamic interactive
   capabilities.  See section 7 of [RFC3236].

   In addition, the scripting language can be accessed by both the XHTML
   and the VoiceXML 2.0 markup embedded in the XHTML+Voice document.
   See section 1.3.1.5 of [XPLUSV12].

      Interoperability considerations :

   Because XHTML+Voice is built upon W3C standard recommendations, it is
   designed to be interoperable across a wide range of platforms and
   client devices.  Because the extensions to XHTML are identified by
   their namespaces, all browsers that have namespace support can run an
   XHTML+Voice document as an XHTML document without voice interaction.
 
     Published specification:

         The latest published version of XHTML+Voice is [XPLUSV12].

      Applications which use this media type:

         XHTML+Voice documents are intended to be deployed on the World
         Wide Web and rendered by multimodal browsers that support the
         visual and voice modes of interaction.  Because XHTML+Voice is
         an application of XML, authors can expect XHTML+Voice user
         agents to be conformant XML 1.0 [XML] processors.  See section
         2 of [RFC3236].

      Additional information:

         Magic number(s):  There is no single string that is always
             present.
         File extension(s): mxml, xhvml, xvml, xvm
         Macintosh File Type Code(s): TEXT

      Person & email address to contact for further information:

         Gerald M. McCobb
         [email-masked]

      Intended usage: COMMON

      Author/Change controller: Gerald McCobb

      Further information:

4. Fragment Identifiers

   See section 3 of [RFC3236].  Following [RFC3236], fragment

McCobb                   Expires Oct. 1, 2005                   [Page 3]

Internet-Draft   XHTML+Voice - application/xhtml+voice+xml April 1, 2005

   identifiers for XHTML+Voice documents designate the element with the
   corresponding ID attribute value (see [XML] section 3.3.1).

   While XHTML+Voice adds new ID attributes with fragment identifier
   namespaces that are not in the same namespace as XHTML, the fragment
   identifiers are processed in the same namespace as the ID attribute's
   namespace.

5. Recognizing XHTML+Voice files

   Because XHTML+Voice is XML, an XHTML+Voice document [optionally]
   starts with an XML declaration which begins with "<?xml" and has a
   DOCTYPE declaration "<!DOCTYPE html".  XHTML+Voice 1.2 has the
   following DOCTYPE declaration:
 
   <!DOCTYPE html PUBLIC "-//VoiceXML Forum//DTD XHTML+Voice 1.2//EN"
"http://www.voicexml.org/specs/multimodal/x+v/12/dtd/xhtml+voice12.dtd">
 
   Because XHTML+Voice is in the XHTML family of languages, the root
   element of an XHTML+Voice document is 'html' and '<html' can be found
   near the top of the document. 

6. Security Considerations

   Security considerations for this media type are discussed in the MIME
   type registration that appears in section 3.

7. Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2396]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifiers (URI): Generic Syntax", RFC 2396,
              August 1998.

   [RFC3023]  Murata, M., St. Laurent, S., and D. Kohn, "XML Media
              Types", RFC 3023, January 2001.

   [RFC3236]  Baker, M., Stark, P., "The 'application/xhtml+xml' Media
              Type", RFC 3236, January 2002.

   [XML]      "Extensible Markup Language (XML) 1.0", W3C
              Recommendation.  Available at <http://www.w3.org/TR/REC-
              xml> (or <http://www.w3.org/TR/2000/REC-xml-20001006>).

   [XHTMLMOD] "Modularization of XHTML," 10 April, 2001, Murray Altheim,
              Frank Boumphrey, Sam Dooley, et al, W3C Recommendation, 
              http://www.w3.org/TR/xhtml-modularization/

McCobb                   Expires Oct. 1, 2005                   [Page 4]

Internet-Draft   XHTML+Voice - application/xhtml+voice+xml April 1, 2005

   [XHTML11]  "XHTML 1.1 - Module-based XHTML," 31 May 2001, Murray 
              Altheim, Shane McCarron, W3C Recommendation,
              http://www.w3.org/TR/xhtml11/.

   [DOM2EV]   "Document Object Model Level 2 Events Specification," 
              Tom Pixley, 2000.  W3C Recommendation,
              http://www.w3.org/TR/DOM-Level-2-Events/.

   [XMLEVNTS] "XML Events - An events syntax for XML", Steven
              Pemberton, T. V. Raman, and Shane McCarron, 2002.  W3C
              Recommendation, http://www.w3.org/TR/xml-events/.
   [XPLUSV12] "XHTML+Voice Profile 1.2," 16 March 2004, J. Axelsson,
              et al, http://www.voicexml.org/specs/multimodal/x+v/12/

   [VXML20]   "Voice Extensible Markup Language (VoiceXML)," 16 March
              2004, Scott McGlashan et al, W3C Recommendation,
              http://www.w3.org/TR/voicexml20/.

8. Authors' Address

   Gerald M. McCobb
   IBM Corporation
   8051 Congress Avenue, Office 2019
   Boca Raton, Florida 33487
   USA

   Phone: +1-561-862-2109
   Fax:   +1-561-862-3922
   EMail: [email-masked]

9. Full Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on 
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 
   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

   Intellectual Property

   The IETF takes no position regarding the validity or scope of any

McCobb                   Expires Oct. 1, 2005                   [Page 5]

Internet-Draft   XHTML+Voice - application/xhtml+voice+xml April 1, 2005

   Intellectual Property Rights or other rights that might be claimed 
   to pertain to the implementation or use of the technology described 
   in this document or the extent to which any license under such 
   rights might or might not be available; nor does it represent that 
   it has made any independent effort to identify any such rights. 
   Information on the procedures with respect to rights in RFC 
   documents can be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use
   of such proprietary rights by implementers or users of this 
   specification can be obtained from the IETF on-line IPR repository 
   at http://www.ietf.org/ipr. 

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   [email-masked].

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Mccobb                   Expires May 15, 2005                   [Page 6]

Regards,
Gerald McCobb
IBM
8051 Congress Avenue
Boca Raton, FL 33487
Tel. # 561-862-2109 T/L 975-2109

Bjoern Hoehrmann <[email-masked]>
03/26/2005 06:06 PM
 
        To:     Gerald McCobb/Boca Raton/IBM@IBMUS
        cc:     [email-masked], [email-masked]
        Subject:        Re: Request for comments regarding 
draft-mccobb-xplusv-media-type-01

* Gerald McCobb wrote:
>2.1 application/xhtml+voice+xml Usage
>
>   The application/xhtml+voice+xml media type is intended to be a media
>   descriptor for XHTML+Voice documents.
>
>   This media type registration is not intended for email usage.

The draft does not really explain why there is a need for such a
type in the first place; why don't you use application/xhtml+xml?

>      Optional parameters:
>   version:  refers to the XHTML+Voice language version in the document.
>             Acceptable values are 1.0, 1.1, and 1.2 (default).

What are the processing requirements for this parameter?

>   charset:  has the same meaning as the text/html media type.  See
>   section 2 of [RFC 2854].

A word seems to be missing here. It is not really clear why the draft
refers to RFC 2854 rather than RFC 3023 or RFC 3236. 

>      Security considerations:
> 
>   XHTML+Voice is an extension of XHTML and has the same security issues
>   as XHTML.  These include interpreting anchors and forms in HTML
>   documents, and scripting languages and other dynamic interactive
>   capabilities.  See section 7 of [RFC 2854].

So the extensions to XHTML have no security considerations?

>         File extension(s): html, htm, mxml, xvml

I don't think .html and .htm should be listed here, they are already in
common use for application/xhtml+xml and text/html.

>4. Fragment Identifiers
>
>   See section 3 of [RFC 2854].

It is unclear what this means, RFC 2854 and RFC 3236 have inconsistent
rules for fragment identifiers and XHTML+Voice adds new ID attributes
so that the fragment identifier namespaces are different.

>6. Security Considerations
>
>   Security considerations for this media type are discussed in the MIME
>   type registration that appears in section 4.

Section 4 has no security considerations...

>7. References

The draft should be clear about which of these references are
informative and which normative.
-- 
Bj?rn H?hrmann ? mailto:[email-masked] ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/ietf-types/attachments/20050421/e3f4518f/attachment.html
>From [email-masked]  Fri Apr 29 20:26:37 2005
From: sla at ucolick.org (Steve Allen)
Date: Tue Jan  3 16:22:59 2006
Subject: MIME media types in RFC 4047
Message-ID: <[email-masked]>

We have been informed that RFC 4047 is published.

RFC 4047 defines two new top-level MIME media types:
image/fits
application/fits

The IANA web pages
http://www.iana.org/assignments/media-types/application/
http://www.iana.org/assignments/media-types/image/
have not been updated to indicate that publication
has occurred.

Do the authors of the RFC need to make any further explicit request to
the IANA, or should we simply await the next update?

--
Steve Allen          UCO/Lick Observatory       Santa Cruz, CA 95064
[email-masked]      Voice: +1 831 459 3046     http://www.ucolick.org/~sla
PGP: 1024/E46978C5   F6 78 D1 10 62 94 8F 2E    49 89 0E FE 26 B4 14 93

From: mankin at psg.com (Allison Mankin)
Date: Tue Jan  3 16:22:59 2006
Subject: Transport Area requests Media Type review for application/conference-info+xml
Message-ID: <[email-masked]>

The Transport Area requests a Media Type review for the 
proposed new type application/conference-info+xml, intended
for the IETF tree, as a Proposed Standard, specified in 
draft-ietf-sipping-conference-package-10.txt

Please provide any comments by 4 May 2005.

Thanks,

Allison

From: moore at cs.utk.edu (Keith Moore)
Date: Tue Jan  3 16:22:59 2006
Subject: regarding your comments on proposed media type text/troff' to Informational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> On Tue April 19 2005 15:14, Keith Moore wrote:
> > > You cited an out-of-context excerpt from RFC 2046 section 4.5.1
> > > (Octet-Stream Subtype), which is not directly relevant:
> > > 
> > > 1. it concerns application software implementation issues rather than
> > >    media type definitions, parameters, content, or registration
> > > 
> > > 2. it is specific to the application/octet-stream media subtype, which
> > >    is in a completely different media type category.
> > 
> > I've already explained why the text is relevant despite the above.
> 
> I don't buy your explanation; it seems to be predicated on an assumption
> that a certain vendor will attempt automatic interpretation of parameter
> value content -- that vendor not being likely to want to support troff,
> which is a direct competitor to said vendor's products.

Your assumptions about my assumptions are incorrect.

> Would you really be happier if it were defined as a strictly human-readable
> text value?

If you defined it in such a way that it could say whatever it wanted to
a human (and not, say, as a command that the human was expected to type),
yes, that would be more acceptable.  Since parameters are rarely 
presented to humans, it wouldn't IMHO be very useful to have such a 
parameter.

> > It is well established that email may be used to send executable content,
> > but we try to discourage having ways that make it easy for the email
> > reader to distinguish executable content from non-executable content
> > and execute it.
> 
> Surely one would like to encourage, rather than discourage, easy
> differentiation of executable and non-executable content.

Not when you look at what actually happens in practice when you do that.

> > The purpose of content-type parameters is for machine interpretation rather 
> > than human readability.
> 
> There is nothing in the core MIME RFCs or draft successors that requires
> machine interpretation.

true.  

> If a parameter is defined as
> human-readable information, then the appropriate action for a UA is to
> display the content to the user.

It's not going to happen, as UAs don't special-case handling of most
content-types.  (now maybe the plugin for the content-type could 
display such content to the user, but that doesn't seem much more
likely given common practices).

Keith

From: moore at cs.utk.edu (Keith Moore)
Date: Tue Jan  3 16:22:59 2006
Subject: regarding your comments on proposed media type text/troff' to Informational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> On Tue April 19 2005 15:14, Keith Moore wrote:
> > > You cited an out-of-context excerpt from RFC 2046 section 4.5.1
> > > (Octet-Stream Subtype), which is not directly relevant:
> > > 
> > > 1. it concerns application software implementation issues rather than
> > >    media type definitions, parameters, content, or registration
> > > 
> > > 2. it is specific to the application/octet-stream media subtype, which
> > >    is in a completely different media type category.
> > 
> > I've already explained why the text is relevant despite the above.
> 
> I don't buy your explanation; it seems to be predicated on an assumption
> that a certain vendor will attempt automatic interpretation of parameter
> value content -- that vendor not being likely to want to support troff,
> which is a direct competitor to said vendor's products.

Your assumptions about my assumptions are incorrect.

> Would you really be happier if it were defined as a strictly human-readable
> text value?

If you defined it in such a way that it could say whatever it wanted to
a human (and not, say, as a command that the human was expected to type),
yes, that would be more acceptable.  Since parameters are rarely 
presented to humans, it wouldn't IMHO be very useful to have such a 
parameter.

> > It is well established that email may be used to send executable content,
> > but we try to discourage having ways that make it easy for the email
> > reader to distinguish executable content from non-executable content
> > and execute it.
> 
> Surely one would like to encourage, rather than discourage, easy
> differentiation of executable and non-executable content.

Not when you look at what actually happens in practice when you do that.

> > The purpose of content-type parameters is for machine interpretation rather 
> > than human readability.
> 
> There is nothing in the core MIME RFCs or draft successors that requires
> machine interpretation.

true.  

> If a parameter is defined as
> human-readable information, then the appropriate action for a UA is to
> display the content to the user.

It's not going to happen, as UAs don't special-case handling of most
content-types.  (now maybe the plugin for the content-type could 
display such content to the user, but that doesn't seem much more
likely given common practices).

Keith

From: blilly at erols.com (Bruce Lilly)
Date: Tue Jan  3 16:22:59 2006
Subject: regarding your comments on proposed media type text/troff'toInformational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Tue April 19 2005 23:22, Larry Masinter wrote:

> You give, as your justification for having a process
> parameter for text/troff, the use case that the receiver
> might automatically determine whether remote content
> is processable, and avoid downloading content that it
> couldn't process.

I believe that I did not say "automatically".  I meant that a
human recipient could decide whether or not to retrieve content
based on information supplied.
 
> > See the issues regarding retrieval of sizable remote content.
> 
> However, this use case doesn't make any sense. If,
> as you assert, the receiver isn't going to automatically
> process the content anyway, but rely on a person to
> type in the process parameter after somehow verifying
> its safety, then there isn't generally a good ability
> to determine processability. After all, the user, if
> the user wants the content, may very will download
> and install the appropriate macro or processing capabilities.

Due to copyright issues, policy issues, economics, etc., a user might
be unable to install some resource.
 
> You're right that the problem with MIME parameters is
> general. In general, I think it's a bad idea to put
> information in MIME parameters that isn't absolutely
> necessary for automatic processing.

Surely you're not suggesting that a "filename" parameter should be
used in a purely automated manner (i.e. w/o at minimum user veto
power)?

> In general, users 
> *don't* have a file system with multiple text/plain files
> which differ by charset.

I can't speak for the general case, but most files that I generate are
in US-ASCII, a few in iso-8859-1, and a smaller number in other
charsets.  Those that I have in my file systems as obtained from other
sources are in a wide variety of charsets (utf-8, euc-kr, GB2312, utf-7,
etc.).

From: blilly at erols.com (Bruce Lilly)
Date: Tue Jan  3 16:22:59 2006
Subject: regarding your comments on proposed media type text/troff'toInformational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Tue April 19 2005 23:22, Larry Masinter wrote:

> You give, as your justification for having a process
> parameter for text/troff, the use case that the receiver
> might automatically determine whether remote content
> is processable, and avoid downloading content that it
> couldn't process.

I believe that I did not say "automatically".  I meant that a
human recipient could decide whether or not to retrieve content
based on information supplied.
 
> > See the issues regarding retrieval of sizable remote content.
> 
> However, this use case doesn't make any sense. If,
> as you assert, the receiver isn't going to automatically
> process the content anyway, but rely on a person to
> type in the process parameter after somehow verifying
> its safety, then there isn't generally a good ability
> to determine processability. After all, the user, if
> the user wants the content, may very will download
> and install the appropriate macro or processing capabilities.

Due to copyright issues, policy issues, economics, etc., a user might
be unable to install some resource.
 
> You're right that the problem with MIME parameters is
> general. In general, I think it's a bad idea to put
> information in MIME parameters that isn't absolutely
> necessary for automatic processing.

Surely you're not suggesting that a "filename" parameter should be
used in a purely automated manner (i.e. w/o at minimum user veto
power)?

> In general, users 
> *don't* have a file system with multiple text/plain files
> which differ by charset.

I can't speak for the general case, but most files that I generate are
in US-ASCII, a few in iso-8859-1, and a smaller number in other
charsets.  Those that I have in my file systems as obtained from other
sources are in a wide variety of charsets (utf-8, euc-kr, GB2312, utf-7,
etc.).

From: tony at att.com (Tony Hansen)
Date: Tue Jan  3 16:22:59 2006
Subject: regarding your comments on proposed media type text/troff' to Informational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

 From a process point of view, can we declare consensus on removing the 
process= parameter?

I see lots of arguments by lots of people against the process= 
parameter. Bruce, the author, is the only one who seems to be arguing 
for the parameter.

There seems to be consensus on the rest of the document moving forward 
essentially as written.

Bruce, would you be willing to declare that the skirmish was lost, but 
the battle won, and republish the document without the process= parameter?

	Tony Hansen
	[email-masked]

From: blilly at erols.com (Bruce Lilly)
Date: Tue Jan  3 16:22:59 2006
Subject: regarding your comments on proposed media type text/troff' to Informational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Tue April 19 2005 15:14, Keith Moore wrote:
> > You cited an out-of-context excerpt from RFC 2046 section 4.5.1
> > (Octet-Stream Subtype), which is not directly relevant:
> > 
> > 1. it concerns application software implementation issues rather than
> >    media type definitions, parameters, content, or registration
> > 
> > 2. it is specific to the application/octet-stream media subtype, which
> >    is in a completely different media type category.
> 
> I've already explained why the text is relevant despite the above.

I don't buy your explanation; it seems to be predicated on an assumption
that a certain vendor will attempt automatic interpretation of parameter
value content -- that vendor not being likely to want to support troff,
which is a direct competitor to said vendor's products.

> What I meant (as if you couldn't figure this out) is that it doesn't have
> to be defined the way you want it to be defined in order for the type to
> be useful.

Would you really be happier if it were defined as a strictly human-readable
text value?
 
> It is well established that email may be used to send executable content,
> but we try to discourage having ways that make it easy for the email
> reader to distinguish executable content from non-executable content
> and execute it.

Surely one would like to encourage, rather than discourage, easy
differentiation of executable and non-executable content.

> > Since the parameter is human-readable
> > information about the media type, *in* a parameter (which is not executable),
> 
> The purpose of content-type parameters is for machine interpretation rather 
> than human readability.

There is nothing in the core MIME RFCs or draft successors that requires
machine interpretation. RFC 2048 says "to convey additional information";
its draft successor uses the same phrase.  If a parameter is defined as
human-readable information, then the appropriate action for a UA is to
display the content to the user.

Each defined media type and subtype may specify any number of parameters,
and behavior is indicated by each specification.  A given parameter in a
given Content-Type field for a specified media type and subtype has to
be interpreted per the parameter specification for that subtype or type
(in the case of an inherited parameter). As noted in RFC 2045 "There are
NO globally-meaningful parameters that apply to all media types."

From: blilly at erols.com (Bruce Lilly)
Date: Tue Jan  3 16:22:59 2006
Subject: regarding your comments on proposed media type text/troff' to Informational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Tue April 19 2005 15:14, Keith Moore wrote:
> > You cited an out-of-context excerpt from RFC 2046 section 4.5.1
> > (Octet-Stream Subtype), which is not directly relevant:
> > 
> > 1. it concerns application software implementation issues rather than
> >    media type definitions, parameters, content, or registration
> > 
> > 2. it is specific to the application/octet-stream media subtype, which
> >    is in a completely different media type category.
> 
> I've already explained why the text is relevant despite the above.

I don't buy your explanation; it seems to be predicated on an assumption
that a certain vendor will attempt automatic interpretation of parameter
value content -- that vendor not being likely to want to support troff,
which is a direct competitor to said vendor's products.

> What I meant (as if you couldn't figure this out) is that it doesn't have
> to be defined the way you want it to be defined in order for the type to
> be useful.

Would you really be happier if it were defined as a strictly human-readable
text value?
 
> It is well established that email may be used to send executable content,
> but we try to discourage having ways that make it easy for the email
> reader to distinguish executable content from non-executable content
> and execute it.

Surely one would like to encourage, rather than discourage, easy
differentiation of executable and non-executable content.

> > Since the parameter is human-readable
> > information about the media type, *in* a parameter (which is not executable),
> 
> The purpose of content-type parameters is for machine interpretation rather 
> than human readability.

There is nothing in the core MIME RFCs or draft successors that requires
machine interpretation. RFC 2048 says "to convey additional information";
its draft successor uses the same phrase.  If a parameter is defined as
human-readable information, then the appropriate action for a UA is to
display the content to the user.

Each defined media type and subtype may specify any number of parameters,
and behavior is indicated by each specification.  A given parameter in a
given Content-Type field for a specified media type and subtype has to
be interpreted per the parameter specification for that subtype or type
(in the case of an inherited parameter). As noted in RFC 2045 "There are
NO globally-meaningful parameters that apply to all media types."

From: distobj at acm.org (Mark Baker)
Date: Wed Apr 20 20:13:55 2005
Subject: For review: application/atom+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

[ CC: IESG, since I suppose this counts as a last call comment ]

Mark,

Congrats on going to last call with the atompub format! -

http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-08.txt

But I note that my comment[1] on the lack of any mention of the existing
use of application/atom+xml with the incompatible Atom 0.3 content
didn't make it in.  Though not widespread, my understanding (though I'd
be happy to be corrected!), at least at the time that you first drew up
this media type[2], was that it was in use[3].  I certainly don't feel
that this is a big enough problem to warrant a new media type, but I do
think it should be flagged to implementors.

Also, I noticed something else that I missed my first time through ...

On Wed, Apr 06, 2005 at 08:41:08PM -0700, Mark Nottingham wrote:
>    Additional information:
> 
>    Magic number(s): As specified for "application/xml" in [RFC3023],
>       section 3.2.

Based on my understanding of the purpose of magic numbers, I think
referencing another spec's magic number algorithm to be prima facie
incorrect.  What I think should be there is information that, as
uniquely as possible, identifies Atom documents, and RFC 3023 can, of
course, only help with identifying XML documents.  So I'd suggest either
adding something about the root namespace value (if indeed the spec
requires that the root element always be from the Atom namespace?) as I
did for XHTML[4], or else just saying "Magic Number: None" (as we did
for SOAP[5], in effect, by not providing an algorithm).

Cheers,

 [1] http://eikenes.alvestrand.no/pipermail/ietf-types/2005-April/000678.html
 [2] http://www.mnot.net/drafts/draft-nottingham-atom-format-02.html
 [3] http://diveintomark.org/archives/2003/12/13/atom03
 [4] http://www.ietf.org/rfc/rfc3236.txt
 [5] http://www.ietf.org/rfc/rfc3902.txt

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
>From [email-masked]  Wed Apr 20 20:58:28 2005
From: blilly at erols.com (Bruce Lilly)
Date: Wed Apr 20 20:58:45 2005
Subject: regarding your comments on proposed media type text/troff' to
	Informational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Tue April 19 2005 15:14, Keith Moore wrote:
> > You cited an out-of-context excerpt from RFC 2046 section 4.5.1
> > (Octet-Stream Subtype), which is not directly relevant:
> > 
> > 1. it concerns application software implementation issues rather than
> >    media type definitions, parameters, content, or registration
> > 
> > 2. it is specific to the application/octet-stream media subtype, which
> >    is in a completely different media type category.
> 
> I've already explained why the text is relevant despite the above.

I don't buy your explanation; it seems to be predicated on an assumption
that a certain vendor will attempt automatic interpretation of parameter
value content -- that vendor not being likely to want to support troff,
which is a direct competitor to said vendor's products.

> What I meant (as if you couldn't figure this out) is that it doesn't have
> to be defined the way you want it to be defined in order for the type to
> be useful.

Would you really be happier if it were defined as a strictly human-readable
text value?
 
> It is well established that email may be used to send executable content,
> but we try to discourage having ways that make it easy for the email
> reader to distinguish executable content from non-executable content
> and execute it.

Surely one would like to encourage, rather than discourage, easy
differentiation of executable and non-executable content.

> > Since the parameter is human-readable
> > information about the media type, *in* a parameter (which is not executable),
> 
> The purpose of content-type parameters is for machine interpretation rather 
> than human readability.

There is nothing in the core MIME RFCs or draft successors that requires
machine interpretation. RFC 2048 says "to convey additional information";
its draft successor uses the same phrase.  If a parameter is defined as
human-readable information, then the appropriate action for a UA is to
display the content to the user.

Each defined media type and subtype may specify any number of parameters,
and behavior is indicated by each specification.  A given parameter in a
given Content-Type field for a specified media type and subtype has to
be interpreted per the parameter specification for that subtype or type
(in the case of an inherited parameter). As noted in RFC 2045 "There are
NO globally-meaningful parameters that apply to all media types."
>From [email-masked]  Wed Apr 20 20:58:28 2005
From: blilly at erols.com (Bruce Lilly)
Date: Wed Apr 20 20:58:49 2005
Subject: regarding your comments on proposed media type text/troff' to
	Informational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Tue April 19 2005 15:14, Keith Moore wrote:
> > You cited an out-of-context excerpt from RFC 2046 section 4.5.1
> > (Octet-Stream Subtype), which is not directly relevant:
> > 
> > 1. it concerns application software implementation issues rather than
> >    media type definitions, parameters, content, or registration
> > 
> > 2. it is specific to the application/octet-stream media subtype, which
> >    is in a completely different media type category.
> 
> I've already explained why the text is relevant despite the above.

I don't buy your explanation; it seems to be predicated on an assumption
that a certain vendor will attempt automatic interpretation of parameter
value content -- that vendor not being likely to want to support troff,
which is a direct competitor to said vendor's products.

> What I meant (as if you couldn't figure this out) is that it doesn't have
> to be defined the way you want it to be defined in order for the type to
> be useful.

Would you really be happier if it were defined as a strictly human-readable
text value?
 
> It is well established that email may be used to send executable content,
> but we try to discourage having ways that make it easy for the email
> reader to distinguish executable content from non-executable content
> and execute it.

Surely one would like to encourage, rather than discourage, easy
differentiation of executable and non-executable content.

> > Since the parameter is human-readable
> > information about the media type, *in* a parameter (which is not executable),
> 
> The purpose of content-type parameters is for machine interpretation rather 
> than human readability.

There is nothing in the core MIME RFCs or draft successors that requires
machine interpretation. RFC 2048 says "to convey additional information";
its draft successor uses the same phrase.  If a parameter is defined as
human-readable information, then the appropriate action for a UA is to
display the content to the user.

Each defined media type and subtype may specify any number of parameters,
and behavior is indicated by each specification.  A given parameter in a
given Content-Type field for a specified media type and subtype has to
be interpreted per the parameter specification for that subtype or type
(in the case of an inherited parameter). As noted in RFC 2045 "There are
NO globally-meaningful parameters that apply to all media types."
>From [email-masked]  Wed Apr 20 21:24:05 2005
From: tony at att.com (Tony Hansen)
Date: Wed Apr 20 21:24:22 2005
Subject: regarding your comments on proposed media type text/troff' to
 Informational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

 From a process point of view, can we declare consensus on removing the 
process= parameter?

I see lots of arguments by lots of people against the process= 
parameter. Bruce, the author, is the only one who seems to be arguing 
for the parameter.

There seems to be consensus on the rest of the document moving forward 
essentially as written.

Bruce, would you be willing to declare that the skirmish was lost, but 
the battle won, and republish the document without the process= parameter?

	Tony Hansen
	[email-masked]
>From [email-masked]  Wed Apr 20 21:32:02 2005
From: blilly at erols.com (Bruce Lilly)
Date: Wed Apr 20 21:32:12 2005
Subject: regarding your comments on proposed media type
	text/troff'toInformational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Tue April 19 2005 23:22, Larry Masinter wrote:

> You give, as your justification for having a process
> parameter for text/troff, the use case that the receiver
> might automatically determine whether remote content
> is processable, and avoid downloading content that it
> couldn't process.

I believe that I did not say "automatically".  I meant that a
human recipient could decide whether or not to retrieve content
based on information supplied.
 
> > See the issues regarding retrieval of sizable remote content.
> 
> However, this use case doesn't make any sense. If,
> as you assert, the receiver isn't going to automatically
> process the content anyway, but rely on a person to
> type in the process parameter after somehow verifying
> its safety, then there isn't generally a good ability
> to determine processability. After all, the user, if
> the user wants the content, may very will download
> and install the appropriate macro or processing capabilities.

Due to copyright issues, policy issues, economics, etc., a user might
be unable to install some resource.
 
> You're right that the problem with MIME parameters is
> general. In general, I think it's a bad idea to put
> information in MIME parameters that isn't absolutely
> necessary for automatic processing.

Surely you're not suggesting that a "filename" parameter should be
used in a purely automated manner (i.e. w/o at minimum user veto
power)?

> In general, users 
> *don't* have a file system with multiple text/plain files
> which differ by charset.

I can't speak for the general case, but most files that I generate are
in US-ASCII, a few in iso-8859-1, and a smaller number in other
charsets.  Those that I have in my file systems as obtained from other
sources are in a wide variety of charsets (utf-8, euc-kr, GB2312, utf-7,
etc.).
>From [email-masked]  Wed Apr 20 21:32:02 2005
From: blilly at erols.com (Bruce Lilly)
Date: Wed Apr 20 21:32:18 2005
Subject: regarding your comments on proposed media type
	text/troff'toInformational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Tue April 19 2005 23:22, Larry Masinter wrote:

> You give, as your justification for having a process
> parameter for text/troff, the use case that the receiver
> might automatically determine whether remote content
> is processable, and avoid downloading content that it
> couldn't process.

I believe that I did not say "automatically".  I meant that a
human recipient could decide whether or not to retrieve content
based on information supplied.
 
> > See the issues regarding retrieval of sizable remote content.
> 
> However, this use case doesn't make any sense. If,
> as you assert, the receiver isn't going to automatically
> process the content anyway, but rely on a person to
> type in the process parameter after somehow verifying
> its safety, then there isn't generally a good ability
> to determine processability. After all, the user, if
> the user wants the content, may very will download
> and install the appropriate macro or processing capabilities.

Due to copyright issues, policy issues, economics, etc., a user might
be unable to install some resource.
 
> You're right that the problem with MIME parameters is
> general. In general, I think it's a bad idea to put
> information in MIME parameters that isn't absolutely
> necessary for automatic processing.

Surely you're not suggesting that a "filename" parameter should be
used in a purely automated manner (i.e. w/o at minimum user veto
power)?

> In general, users 
> *don't* have a file system with multiple text/plain files
> which differ by charset.

I can't speak for the general case, but most files that I generate are
in US-ASCII, a few in iso-8859-1, and a smaller number in other
charsets.  Those that I have in my file systems as obtained from other
sources are in a wide variety of charsets (utf-8, euc-kr, GB2312, utf-7,
etc.).
>From [email-masked]  Wed Apr 20 22:07:38 2005
From: moore at cs.utk.edu (Keith Moore)
Date: Wed Apr 20 22:07:45 2005
Subject: regarding your comments on proposed media type text/troff' to
 Informational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

> On Tue April 19 2005 15:14, Keith Moore wrote:
> > > You cited an out-of-context excerpt from RFC 2046 section 4.5.1
> > > (Octet-Stream Subtype), which is not directly relevant:
> > > 
> > > 1. it concerns application software implementation issues rather than
> > >    media type definitions, parameters, content, or registration
> > > 
> > > 2. it is specific to the application/octet-stream media subtype, which
> > >    is in a completely different media type category.
> > 
> > I've already explained why the text is relevant despite the above.
> 
> I don't buy your explanation; it seems to be predicated on an assumption
> that a certain vendor will attempt automatic interpretation of parameter
> value content -- that vendor not being likely to want to support troff,
> which is a direct competitor to said vendor's products.

Your assumptions about my assumptions are incorrect.

> Would you really be happier if it were defined as a strictly human-readable
> text value?

If you defined it in such a way that it could say whatever it wanted to
a human (and not, say, as a command that the human was expected to type),
yes, that would be more acceptable.  Since parameters are rarely 
presented to humans, it wouldn't IMHO be very useful to have such a 
parameter.

> > It is well established that email may be used to send executable content,
> > but we try to discourage having ways that make it easy for the email
> > reader to distinguish executable content from non-executable content
> > and execute it.
> 
> Surely one would like to encourage, rather than discourage, easy
> differentiation of executable and non-executable content.

Not when you look at what actually happens in practice when you do that.

> > The purpose of content-type parameters is for machine interpretation rather 
> > than human readability.
> 
> There is nothing in the core MIME RFCs or draft successors that requires
> machine interpretation.

true.  

> If a parameter is defined as
> human-readable information, then the appropriate action for a UA is to
> display the content to the user.

It's not going to happen, as UAs don't special-case handling of most
content-types.  (now maybe the plugin for the content-type could 
display such content to the user, but that doesn't seem much more
likely given common practices).

Keith
>From [email-masked]  Wed Apr 20 22:07:38 2005
From: moore at cs.utk.edu (Keith Moore)
Date: Wed Apr 20 22:07:51 2005
Subject: regarding your comments on proposed media type text/troff' to
 Informational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

> On Tue April 19 2005 15:14, Keith Moore wrote:
> > > You cited an out-of-context excerpt from RFC 2046 section 4.5.1
> > > (Octet-Stream Subtype), which is not directly relevant:
> > > 
> > > 1. it concerns application software implementation issues rather than
> > >    media type definitions, parameters, content, or registration
> > > 
> > > 2. it is specific to the application/octet-stream media subtype, which
> > >    is in a completely different media type category.
> > 
> > I've already explained why the text is relevant despite the above.
> 
> I don't buy your explanation; it seems to be predicated on an assumption
> that a certain vendor will attempt automatic interpretation of parameter
> value content -- that vendor not being likely to want to support troff,
> which is a direct competitor to said vendor's products.

Your assumptions about my assumptions are incorrect.

> Would you really be happier if it were defined as a strictly human-readable
> text value?

If you defined it in such a way that it could say whatever it wanted to
a human (and not, say, as a command that the human was expected to type),
yes, that would be more acceptable.  Since parameters are rarely 
presented to humans, it wouldn't IMHO be very useful to have such a 
parameter.

> > It is well established that email may be used to send executable content,
> > but we try to discourage having ways that make it easy for the email
> > reader to distinguish executable content from non-executable content
> > and execute it.
> 
> Surely one would like to encourage, rather than discourage, easy
> differentiation of executable and non-executable content.

Not when you look at what actually happens in practice when you do that.

> > The purpose of content-type parameters is for machine interpretation rather 
> > than human readability.
> 
> There is nothing in the core MIME RFCs or draft successors that requires
> machine interpretation.

true.  

> If a parameter is defined as
> human-readable information, then the appropriate action for a UA is to
> display the content to the user.

It's not going to happen, as UAs don't special-case handling of most
content-types.  (now maybe the plugin for the content-type could 
display such content to the user, but that doesn't seem much more
likely given common practices).

Keith
>From [email-masked]  Thu Apr 21 05:34:31 2005
From: mankin at psg.com (Allison Mankin)
Date: Thu Apr 21 05:34:36 2005
Subject: Transport Area requests Media Type review for
	application/conference-info+xml
Message-ID: <[email-masked]>

The Transport Area requests a Media Type review for the 
proposed new type application/conference-info+xml, intended
for the IETF tree, as a Proposed Standard, specified in 
draft-ietf-sipping-conference-package-10.txt

Please provide any comments by 4 May 2005.

Thanks,

Allison

From: distobj at acm.org (Mark Baker)
Date: Tue Jan  3 16:22:59 2006
Subject: For review: application/atom+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

[ CC: IESG, since I suppose this counts as a last call comment ]

Mark,

Congrats on going to last call with the atompub format! -

http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-08.txt

But I note that my comment[1] on the lack of any mention of the existing
use of application/atom+xml with the incompatible Atom 0.3 content
didn't make it in.  Though not widespread, my understanding (though I'd
be happy to be corrected!), at least at the time that you first drew up
this media type[2], was that it was in use[3].  I certainly don't feel
that this is a big enough problem to warrant a new media type, but I do
think it should be flagged to implementors.

Also, I noticed something else that I missed my first time through ...

On Wed, Apr 06, 2005 at 08:41:08PM -0700, Mark Nottingham wrote:
>    Additional information:
> 
>    Magic number(s): As specified for "application/xml" in [RFC3023],
>       section 3.2.

Based on my understanding of the purpose of magic numbers, I think
referencing another spec's magic number algorithm to be prima facie
incorrect.  What I think should be there is information that, as
uniquely as possible, identifies Atom documents, and RFC 3023 can, of
course, only help with identifying XML documents.  So I'd suggest either
adding something about the root namespace value (if indeed the spec
requires that the root element always be from the Atom namespace?) as I
did for XHTML[4], or else just saying "Magic Number: None" (as we did
for SOAP[5], in effect, by not providing an algorithm).

Cheers,

 [1] http://eikenes.alvestrand.no/pipermail/ietf-types/2005-April/000678.html
 [2] http://www.mnot.net/drafts/draft-nottingham-atom-format-02.html
 [3] http://diveintomark.org/archives/2003/12/13/atom03
 [4] http://www.ietf.org/rfc/rfc3236.txt
 [5] http://www.ietf.org/rfc/rfc3902.txt

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

From: LMM at acm.org (Larry Masinter)
Date: Wed Apr 20 05:22:14 2005
Subject: regarding your comments on proposed media type text/troff'toInformational RFC
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> > I wish you would reply and say why you think your proposal
> > (put processing instructions in a parameter) is better than
> > what I recently proposed as an alternative (put processing
> > instructions in a comment in the body).

You give, as your justification for having a process
parameter for text/troff, the use case that the receiver
might automatically determine whether remote content
is processable, and avoid downloading content that it
couldn't process.

> See the issues regarding retrieval of sizable remote content.

However, this use case doesn't make any sense. If,
as you assert, the receiver isn't going to automatically
process the content anyway, but rely on a person to
type in the process parameter after somehow verifying
its safety, then there isn't generally a good ability
to determine processability. After all, the user, if
the user wants the content, may very will download
and install the appropriate macro or processing capabilities.

You're right that the problem with MIME parameters is
general. In general, I think it's a bad idea to put
information in MIME parameters that isn't absolutely
necessary for automatic processing. In general, users
*don't* have a file system with multiple text/plain files
which differ by charset.

Larry

Larry

From: LMM at acm.org (Larry Masinter)
Date: Tue Jan  3 16:22:59 2006
Subject: regarding your comments on proposed media type text/troff'toInformational RFC
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> > I wish you would reply and say why you think your proposal
> > (put processing instructions in a parameter) is better than
> > what I recently proposed as an alternative (put processing
> > instructions in a comment in the body).

You give, as your justification for having a process
parameter for text/troff, the use case that the receiver
might automatically determine whether remote content
is processable, and avoid downloading content that it
couldn't process.

> See the issues regarding retrieval of sizable remote content.

However, this use case doesn't make any sense. If,
as you assert, the receiver isn't going to automatically
process the content anyway, but rely on a person to
type in the process parameter after somehow verifying
its safety, then there isn't generally a good ability
to determine processability. After all, the user, if
the user wants the content, may very will download
and install the appropriate macro or processing capabilities.

You're right that the problem with MIME parameters is
general. In general, I think it's a bad idea to put
information in MIME parameters that isn't absolutely
necessary for automatic processing. In general, users
*don't* have a file system with multiple text/plain files
which differ by charset.

Larry

Larry

From: moore at cs.utk.edu (Keith Moore)
Date: Tue Apr 19 21:14:32 2005
Subject: regarding your comments on proposed media type text/troff' to Informational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> You cited an out-of-context excerpt from RFC 2046 section 4.5.1
> (Octet-Stream Subtype), which is not directly relevant:
> 
> 1. it concerns application software implementation issues rather than
>    media type definitions, parameters, content, or registration
> 
> 2. it is specific to the application/octet-stream media subtype, which
>    is in a completely different media type category.

I've already explained why the text is relevant despite the above.

> > The process parameter as you have defined it is not an essential part 
> > of this content-type.
> 
> Duh.  That's why it's an optional parameter.  If you don't like it, you
> need not use it.

What I meant (as if you couldn't figure this out) is that it doesn't have
to be defined the way you want it to be defined in order for the type to
be useful.

> > Nor is it likely to be used in the way you assume, 
> > because (as I have already said twice) content-type parameters are 
> > rarely displayed to recipients.
> 
> I can easily see the entire Content-Type field; look at any I-D-announce
> or IETF-Announce list announcement of a draft or RFC -- there are
> message/external-body wrappers with Content-Type and Content-ID fields
> for the media.

Content-type parameters are not displayed in most mail readers.

> > This parameter is just poorly designed, and it's a security 
> > risk, and there's simply not enough justification for it to be defined
> > the way you propose.
> 
> Sending executable content such as a build script as you proposed as an
> alternative would be a security risk.  

It is well established that email may be used to send executable content,
but we try to discourage having ways that make it easy for the email
reader to distinguish executable content from non-executable content
and execute it.

> Since the parameter is human-readable
> information about the media type, *in* a parameter (which is not executable),

The purpose of content-type parameters is for machine interpretation rather 
than human readability.

> there is no inherent security risk aside from social engineering

hogwash.

From: moore at cs.utk.edu (Keith Moore)
Date: Tue Jan  3 16:22:59 2006
Subject: regarding your comments on proposed media type text/troff' to Informational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> You cited an out-of-context excerpt from RFC 2046 section 4.5.1
> (Octet-Stream Subtype), which is not directly relevant:
> 
> 1. it concerns application software implementation issues rather than
>    media type definitions, parameters, content, or registration
> 
> 2. it is specific to the application/octet-stream media subtype, which
>    is in a completely different media type category.

I've already explained why the text is relevant despite the above.

> > The process parameter as you have defined it is not an essential part 
> > of this content-type.
> 
> Duh.  That's why it's an optional parameter.  If you don't like it, you
> need not use it.

What I meant (as if you couldn't figure this out) is that it doesn't have
to be defined the way you want it to be defined in order for the type to
be useful.

> > Nor is it likely to be used in the way you assume, 
> > because (as I have already said twice) content-type parameters are 
> > rarely displayed to recipients.
> 
> I can easily see the entire Content-Type field; look at any I-D-announce
> or IETF-Announce list announcement of a draft or RFC -- there are
> message/external-body wrappers with Content-Type and Content-ID fields
> for the media.

Content-type parameters are not displayed in most mail readers.

> > This parameter is just poorly designed, and it's a security 
> > risk, and there's simply not enough justification for it to be defined
> > the way you propose.
> 
> Sending executable content such as a build script as you proposed as an
> alternative would be a security risk.  

It is well established that email may be used to send executable content,
but we try to discourage having ways that make it easy for the email
reader to distinguish executable content from non-executable content
and execute it.

> Since the parameter is human-readable
> information about the media type, *in* a parameter (which is not executable),

The purpose of content-type parameters is for machine interpretation rather 
than human readability.

> there is no inherent security risk aside from social engineering

hogwash.

From: moore at cs.utk.edu (Keith Moore)
Date: Tue Jan  3 16:22:59 2006
Subject: regarding your comments on proposed media type text/troff' to Informational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> You cited an out-of-context excerpt from RFC 2046 section 4.5.1
> (Octet-Stream Subtype), which is not directly relevant:
> 
> 1. it concerns application software implementation issues rather than
>    media type definitions, parameters, content, or registration
> 
> 2. it is specific to the application/octet-stream media subtype, which
>    is in a completely different media type category.

I've already explained why the text is relevant despite the above.

> > The process parameter as you have defined it is not an essential part 
> > of this content-type.
> 
> Duh.  That's why it's an optional parameter.  If you don't like it, you
> need not use it.

What I meant (as if you couldn't figure this out) is that it doesn't have
to be defined the way you want it to be defined in order for the type to
be useful.

> > Nor is it likely to be used in the way you assume, 
> > because (as I have already said twice) content-type parameters are 
> > rarely displayed to recipients.
> 
> I can easily see the entire Content-Type field; look at any I-D-announce
> or IETF-Announce list announcement of a draft or RFC -- there are
> message/external-body wrappers with Content-Type and Content-ID fields
> for the media.

Content-type parameters are not displayed in most mail readers.

> > This parameter is just poorly designed, and it's a security 
> > risk, and there's simply not enough justification for it to be defined
> > the way you propose.
> 
> Sending executable content such as a build script as you proposed as an
> alternative would be a security risk.  

It is well established that email may be used to send executable content,
but we try to discourage having ways that make it easy for the email
reader to distinguish executable content from non-executable content
and execute it.

> Since the parameter is human-readable
> information about the media type, *in* a parameter (which is not executable),

The purpose of content-type parameters is for machine interpretation rather 
than human readability.

> there is no inherent security risk aside from social engineering

hogwash.

From: blilly at erols.com (Bruce Lilly)
Date: Tue Jan  3 16:22:59 2006
Subject: regarding your comments on proposed media type text/troff' toInformational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Tue April 19 2005 12:24, Larry Masinter wrote:
> I wish you would reply and say why you think your proposal
> (put processing instructions in a parameter) is better than
> what I recently proposed as an alternative (put processing
> instructions in a comment in the body).

I think I was composing just such a response at the same time that
you were composing your message.

> MIME parameters tend to get lost when the MIME bodies are
> pushed through most file systems.

That's a general issue with such file systems. It applies to most
types and parameters.  For that matter, it applies even if MIME
mechanisms aren't used.  Some systems resort to guesses ("heuristics");
others pretend that Bill Shakespeare was wrong, that a name (or portion
thereof) conveys some essential information.

> MIME parameters are hard 
> to set up for HTTP servers; it's difficult to configure
> them to emit widely variable processing instructions, e.g.,
> if you were to have several different text/troff files,
> each with different processing instructions.

The same could be said for several different text/plain files, each
with a different charset.  Solutions to the problem include groping
through the content (unreliable and inefficient) and maintaining a
database of metadata.
 
> If don't REALLY intend for the processing instructions to be
> handled automatically, and you REALLY intend for humans to read
> and interpret them, you're better off bundling them inside
> the body anyway.

See the issues regarding retrieval of sizable remote content.

From: blilly at erols.com (Bruce Lilly)
Date: Tue Jan  3 16:22:59 2006
Subject: regarding your comments on proposed media type text/troff' toInformational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Tue April 19 2005 12:24, Larry Masinter wrote:
> I wish you would reply and say why you think your proposal
> (put processing instructions in a parameter) is better than
> what I recently proposed as an alternative (put processing
> instructions in a comment in the body).

I think I was composing just such a response at the same time that
you were composing your message.

> MIME parameters tend to get lost when the MIME bodies are
> pushed through most file systems.

That's a general issue with such file systems. It applies to most
types and parameters.  For that matter, it applies even if MIME
mechanisms aren't used.  Some systems resort to guesses ("heuristics");
others pretend that Bill Shakespeare was wrong, that a name (or portion
thereof) conveys some essential information.

> MIME parameters are hard 
> to set up for HTTP servers; it's difficult to configure
> them to emit widely variable processing instructions, e.g.,
> if you were to have several different text/troff files,
> each with different processing instructions.

The same could be said for several different text/plain files, each
with a different charset.  Solutions to the problem include groping
through the content (unreliable and inefficient) and maintaining a
database of metadata.
 
> If don't REALLY intend for the processing instructions to be
> handled automatically, and you REALLY intend for humans to read
> and interpret them, you're better off bundling them inside
> the body anyway.

See the issues regarding retrieval of sizable remote content.

From: blilly at erols.com (Bruce Lilly)
Date: Tue Jan  3 16:22:59 2006
Subject: regarding your comments on proposed media type text/troff' to Informational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Tue April 19 2005 13:13, Keith Moore wrote:
> Bruce,
> 
> I've already cited the relevant text

You cited an out-of-context excerpt from RFC 2046 section 4.5.1
(Octet-Stream Subtype), which is not directly relevant:

1. it concerns application software implementation issues rather than
   media type definitions, parameters, content, or registration

2. it is specific to the application/octet-stream media subtype, which
   is in a completely different media type category.

However, some of the considerations of course apply to application
software implementations of other media types, and those are discussed
in the draft, using language similar to (but with RFC 2119 emphasis;
for what that's worth in an Informational RFC) that of the cited section.

> The process parameter as you have defined it is not an essential part 
> of this content-type.

Duh.  That's why it's an optional parameter.  If you don't like it, you
need not use it.

> Nor is it likely to be used in the way you assume, 
> because (as I have already said twice) content-type parameters are 
> rarely displayed to recipients.

I can easily see the entire Content-Type field; look at any I-D-announce
or IETF-Announce list announcement of a draft or RFC -- there are
message/external-body wrappers with Content-Type and Content-ID fields
for the media.

> Nor is the parameter as you have defined 
> it portable to different implementations of troff that have different 
> options.

There is an optional "versions" parameter which can be used to indicate
peculiarities.  However, unless one tries fairly hard, one is unlikely
to encounter incompatible options, as implementations are generally
intended to be compatible, and authors creating content for wide
distribution tend to be careful not to use incompatible features.

> This parameter is just poorly designed, and it's a security 
> risk, and there's simply not enough justification for it to be defined
> the way you propose.

Sending executable content such as a build script as you proposed as an
alternative would be a security risk.  Since the parameter is human-readable
information about the media type, *in* a parameter (which is not executable),
there is no inherent security risk aside from social engineering, and that
exists regardless of any parameters, and regardless of media type.

From: blilly at erols.com (Bruce Lilly)
Date: Tue Jan  3 16:22:59 2006
Subject: regarding your comments on proposed media type text/troff' to Informational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Tue April 19 2005 13:13, Keith Moore wrote:
> Bruce,
> 
> I've already cited the relevant text

You cited an out-of-context excerpt from RFC 2046 section 4.5.1
(Octet-Stream Subtype), which is not directly relevant:

1. it concerns application software implementation issues rather than
   media type definitions, parameters, content, or registration

2. it is specific to the application/octet-stream media subtype, which
   is in a completely different media type category.

However, some of the considerations of course apply to application
software implementations of other media types, and those are discussed
in the draft, using language similar to (but with RFC 2119 emphasis;
for what that's worth in an Informational RFC) that of the cited section.

> The process parameter as you have defined it is not an essential part 
> of this content-type.

Duh.  That's why it's an optional parameter.  If you don't like it, you
need not use it.

> Nor is it likely to be used in the way you assume, 
> because (as I have already said twice) content-type parameters are 
> rarely displayed to recipients.

I can easily see the entire Content-Type field; look at any I-D-announce
or IETF-Announce list announcement of a draft or RFC -- there are
message/external-body wrappers with Content-Type and Content-ID fields
for the media.

> Nor is the parameter as you have defined 
> it portable to different implementations of troff that have different 
> options.

There is an optional "versions" parameter which can be used to indicate
peculiarities.  However, unless one tries fairly hard, one is unlikely
to encounter incompatible options, as implementations are generally
intended to be compatible, and authors creating content for wide
distribution tend to be careful not to use incompatible features.

> This parameter is just poorly designed, and it's a security 
> risk, and there's simply not enough justification for it to be defined
> the way you propose.

Sending executable content such as a build script as you proposed as an
alternative would be a security risk.  Since the parameter is human-readable
information about the media type, *in* a parameter (which is not executable),
there is no inherent security risk aside from social engineering, and that
exists regardless of any parameters, and regardless of media type.

From: moore at cs.utk.edu (Keith Moore)
Date: Tue Apr 19 19:15:27 2005
Subject: regarding your comments on proposed media type text/troff' toInformational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> The more important reason to avoid automatic interpretation is that
> is is unsafe to do so.

ah, if only implementors and users had common sense.  experience
indicates that they do not.   expecting them to do so, in the absence
of a good reason, is imprudent.
>From [email-masked]  Tue Apr 19 19:15:17 2005
From: moore at cs.utk.edu (Keith Moore)
Date: Tue Apr 19 19:15:28 2005
Subject: regarding your comments on proposed media type text/troff'
 toInformational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

> The more important reason to avoid automatic interpretation is that
> is is unsafe to do so.

ah, if only implementors and users had common sense.  experience
indicates that they do not.   expecting them to do so, in the absence
of a good reason, is imprudent.
>From [email-masked]  Tue Apr 19 20:54:53 2005
From: blilly at erols.com (Bruce Lilly)
Date: Tue Apr 19 20:55:12 2005
Subject: regarding your comments on proposed media type text/troff' to
	Informational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Tue April 19 2005 13:13, Keith Moore wrote:
> Bruce,
> 
> I've already cited the relevant text

You cited an out-of-context excerpt from RFC 2046 section 4.5.1
(Octet-Stream Subtype), which is not directly relevant:

1. it concerns application software implementation issues rather than
   media type definitions, parameters, content, or registration

2. it is specific to the application/octet-stream media subtype, which
   is in a completely different media type category.

However, some of the considerations of course apply to application
software implementations of other media types, and those are discussed
in the draft, using language similar to (but with RFC 2119 emphasis;
for what that's worth in an Informational RFC) that of the cited section.

> The process parameter as you have defined it is not an essential part 
> of this content-type.

Duh.  That's why it's an optional parameter.  If you don't like it, you
need not use it.

> Nor is it likely to be used in the way you assume, 
> because (as I have already said twice) content-type parameters are 
> rarely displayed to recipients.

I can easily see the entire Content-Type field; look at any I-D-announce
or IETF-Announce list announcement of a draft or RFC -- there are
message/external-body wrappers with Content-Type and Content-ID fields
for the media.

> Nor is the parameter as you have defined 
> it portable to different implementations of troff that have different 
> options.

There is an optional "versions" parameter which can be used to indicate
peculiarities.  However, unless one tries fairly hard, one is unlikely
to encounter incompatible options, as implementations are generally
intended to be compatible, and authors creating content for wide
distribution tend to be careful not to use incompatible features.

> This parameter is just poorly designed, and it's a security 
> risk, and there's simply not enough justification for it to be defined
> the way you propose.

Sending executable content such as a build script as you proposed as an
alternative would be a security risk.  Since the parameter is human-readable
information about the media type, *in* a parameter (which is not executable),
there is no inherent security risk aside from social engineering, and that
exists regardless of any parameters, and regardless of media type.
>From [email-masked]  Tue Apr 19 20:54:53 2005
From: blilly at erols.com (Bruce Lilly)
Date: Tue Apr 19 20:55:17 2005
Subject: regarding your comments on proposed media type text/troff' to
	Informational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Tue April 19 2005 13:13, Keith Moore wrote:
> Bruce,
> 
> I've already cited the relevant text

You cited an out-of-context excerpt from RFC 2046 section 4.5.1
(Octet-Stream Subtype), which is not directly relevant:

1. it concerns application software implementation issues rather than
   media type definitions, parameters, content, or registration

2. it is specific to the application/octet-stream media subtype, which
   is in a completely different media type category.

However, some of the considerations of course apply to application
software implementations of other media types, and those are discussed
in the draft, using language similar to (but with RFC 2119 emphasis;
for what that's worth in an Informational RFC) that of the cited section.

> The process parameter as you have defined it is not an essential part 
> of this content-type.

Duh.  That's why it's an optional parameter.  If you don't like it, you
need not use it.

> Nor is it likely to be used in the way you assume, 
> because (as I have already said twice) content-type parameters are 
> rarely displayed to recipients.

I can easily see the entire Content-Type field; look at any I-D-announce
or IETF-Announce list announcement of a draft or RFC -- there are
message/external-body wrappers with Content-Type and Content-ID fields
for the media.

> Nor is the parameter as you have defined 
> it portable to different implementations of troff that have different 
> options.

There is an optional "versions" parameter which can be used to indicate
peculiarities.  However, unless one tries fairly hard, one is unlikely
to encounter incompatible options, as implementations are generally
intended to be compatible, and authors creating content for wide
distribution tend to be careful not to use incompatible features.

> This parameter is just poorly designed, and it's a security 
> risk, and there's simply not enough justification for it to be defined
> the way you propose.

Sending executable content such as a build script as you proposed as an
alternative would be a security risk.  Since the parameter is human-readable
information about the media type, *in* a parameter (which is not executable),
there is no inherent security risk aside from social engineering, and that
exists regardless of any parameters, and regardless of media type.
>From [email-masked]  Tue Apr 19 21:08:36 2005
From: blilly at erols.com (Bruce Lilly)
Date: Tue Apr 19 21:08:52 2005
Subject: regarding your comments on proposed media type text/troff'
	toInformational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Tue April 19 2005 12:24, Larry Masinter wrote:
> I wish you would reply and say why you think your proposal
> (put processing instructions in a parameter) is better than
> what I recently proposed as an alternative (put processing
> instructions in a comment in the body).

I think I was composing just such a response at the same time that
you were composing your message.

> MIME parameters tend to get lost when the MIME bodies are
> pushed through most file systems.

That's a general issue with such file systems. It applies to most
types and parameters.  For that matter, it applies even if MIME
mechanisms aren't used.  Some systems resort to guesses ("heuristics");
others pretend that Bill Shakespeare was wrong, that a name (or portion
thereof) conveys some essential information.

> MIME parameters are hard 
> to set up for HTTP servers; it's difficult to configure
> them to emit widely variable processing instructions, e.g.,
> if you were to have several different text/troff files,
> each with different processing instructions.

The same could be said for several different text/plain files, each
with a different charset.  Solutions to the problem include groping
through the content (unreliable and inefficient) and maintaining a
database of metadata.
 
> If don't REALLY intend for the processing instructions to be
> handled automatically, and you REALLY intend for humans to read
> and interpret them, you're better off bundling them inside
> the body anyway.

See the issues regarding retrieval of sizable remote content.
>From [email-masked]  Tue Apr 19 21:08:36 2005
From: blilly at erols.com (Bruce Lilly)
Date: Tue Apr 19 21:08:57 2005
Subject: regarding your comments on proposed media type text/troff'
	toInformational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Tue April 19 2005 12:24, Larry Masinter wrote:
> I wish you would reply and say why you think your proposal
> (put processing instructions in a parameter) is better than
> what I recently proposed as an alternative (put processing
> instructions in a comment in the body).

I think I was composing just such a response at the same time that
you were composing your message.

> MIME parameters tend to get lost when the MIME bodies are
> pushed through most file systems.

That's a general issue with such file systems. It applies to most
types and parameters.  For that matter, it applies even if MIME
mechanisms aren't used.  Some systems resort to guesses ("heuristics");
others pretend that Bill Shakespeare was wrong, that a name (or portion
thereof) conveys some essential information.

> MIME parameters are hard 
> to set up for HTTP servers; it's difficult to configure
> them to emit widely variable processing instructions, e.g.,
> if you were to have several different text/troff files,
> each with different processing instructions.

The same could be said for several different text/plain files, each
with a different charset.  Solutions to the problem include groping
through the content (unreliable and inefficient) and maintaining a
database of metadata.
 
> If don't REALLY intend for the processing instructions to be
> handled automatically, and you REALLY intend for humans to read
> and interpret them, you're better off bundling them inside
> the body anyway.

See the issues regarding retrieval of sizable remote content.
>From [email-masked]  Tue Apr 19 21:14:19 2005
From: moore at cs.utk.edu (Keith Moore)
Date: Tue Apr 19 21:14:27 2005
Subject: regarding your comments on proposed media type text/troff' to
 Informational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

> You cited an out-of-context excerpt from RFC 2046 section 4.5.1
> (Octet-Stream Subtype), which is not directly relevant:
> 
> 1. it concerns application software implementation issues rather than
>    media type definitions, parameters, content, or registration
> 
> 2. it is specific to the application/octet-stream media subtype, which
>    is in a completely different media type category.

I've already explained why the text is relevant despite the above.

> > The process parameter as you have defined it is not an essential part 
> > of this content-type.
> 
> Duh.  That's why it's an optional parameter.  If you don't like it, you
> need not use it.

What I meant (as if you couldn't figure this out) is that it doesn't have
to be defined the way you want it to be defined in order for the type to
be useful.

> > Nor is it likely to be used in the way you assume, 
> > because (as I have already said twice) content-type parameters are 
> > rarely displayed to recipients.
> 
> I can easily see the entire Content-Type field; look at any I-D-announce
> or IETF-Announce list announcement of a draft or RFC -- there are
> message/external-body wrappers with Content-Type and Content-ID fields
> for the media.

Content-type parameters are not displayed in most mail readers.

> > This parameter is just poorly designed, and it's a security 
> > risk, and there's simply not enough justification for it to be defined
> > the way you propose.
> 
> Sending executable content such as a build script as you proposed as an
> alternative would be a security risk.  

It is well established that email may be used to send executable content,
but we try to discourage having ways that make it easy for the email
reader to distinguish executable content from non-executable content
and execute it.

> Since the parameter is human-readable
> information about the media type, *in* a parameter (which is not executable),

The purpose of content-type parameters is for machine interpretation rather 
than human readability.

> there is no inherent security risk aside from social engineering

hogwash.

From: moore at cs.utk.edu (Keith Moore)
Date: Tue Jan  3 16:22:59 2006
Subject: regarding your comments on proposed media type text/troff' toInformational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> The more important reason to avoid automatic interpretation is that
> is is unsafe to do so.

ah, if only implementors and users had common sense.  experience
indicates that they do not.   expecting them to do so, in the absence
of a good reason, is imprudent.

From: moore at cs.utk.edu (Keith Moore)
Date: Tue Jan  3 16:22:59 2006
Subject: regarding your comments on proposed media type text/troff' toInformational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> The more important reason to avoid automatic interpretation is that
> is is unsafe to do so.

ah, if only implementors and users had common sense.  experience
indicates that they do not.   expecting them to do so, in the absence
of a good reason, is imprudent.

From: moore at cs.utk.edu (Keith Moore)
Date: Tue Apr 19 19:13:24 2005
Subject: regarding your comments on proposed media type text/troff' to Informational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Bruce,

I've already cited the relevant text, and given you several reasons why
this proposal is not acceptable.  Other people have also objected to
the proposal for the same reasons.  

The process parameter as you have defined it is not an essential part 
of this content-type.  Nor is it likely to be used in the way you assume,
because (as I have already said twice) content-type parameters are 
rarely displayed to recipients.   Nor is the parameter as you have defined
it portable to different implementations of troff that have different 
options.  This parameter is just poorly designed, and it's a security
risk, and there's simply not enough justification for it to be defined
the way you propose.

From: moore at cs.utk.edu (Keith Moore)
Date: Tue Jan  3 16:22:59 2006
Subject: regarding your comments on proposed media type text/troff' to Informational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Bruce,

I've already cited the relevant text, and given you several reasons why
this proposal is not acceptable.  Other people have also objected to
the proposal for the same reasons.  

The process parameter as you have defined it is not an essential part 
of this content-type.  Nor is it likely to be used in the way you assume,
because (as I have already said twice) content-type parameters are 
rarely displayed to recipients.   Nor is the parameter as you have defined
it portable to different implementations of troff that have different 
options.  This parameter is just poorly designed, and it's a security
risk, and there's simply not enough justification for it to be defined
the way you propose.

From: moore at cs.utk.edu (Keith Moore)
Date: Tue Jan  3 16:22:59 2006
Subject: regarding your comments on proposed media type text/troff' to Informational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Bruce,

I've already cited the relevant text, and given you several reasons why
this proposal is not acceptable.  Other people have also objected to
the proposal for the same reasons.  

The process parameter as you have defined it is not an essential part 
of this content-type.  Nor is it likely to be used in the way you assume,
because (as I have already said twice) content-type parameters are 
rarely displayed to recipients.   Nor is the parameter as you have defined
it portable to different implementations of troff that have different 
options.  This parameter is just poorly designed, and it's a security
risk, and there's simply not enough justification for it to be defined
the way you propose.

From: blilly at erols.com (Bruce Lilly)
Date: Tue Apr 19 18:30:49 2005
Subject: regarding your comments on proposed media type text/troff' toInformational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Larry,

Thanks for your comments.

On Mon April 18 2005 15:06, Larry Masinter wrote:
> How about removing the "process" parameter and instead suggesting that
> instructions be included in the source document, in a comment,
> explaining how to process the document, including possible
> recommended command lines, environment variables, preprocessors,
> warnings.

The draft does note that it is possible to include such information
in comments, and cautions against conflicting information.

> Make it explicit that there is no standard format for such
> instructions,

That's one of the problems for authors and recipients.

> and that receivers of text/troff documents should 
> not attempt to try to automatically interpret such instructions
> because instructions might vary widely in format, language,
> and syntax, or contain preconditions or warnings or other
> information.

The more important reason to avoid automatic interpretation is that
is is unsafe to do so.

> It would even be reasonable to suggest, to the creators
> of text/troff content, the complete set of information
> that would be required in such instructions, and even
> some useful guidelines about how to write them in a way
> that others will have good luck interpreting them.
> But by not creating a standard syntax, you will avoid
> encouraging writers of receivers to build automatic
> launch information.

One problem with not having standard syntax is that it may be
impossible for a recipient to understand prose instructions
(would you be able to comprehend instructions in Arabic or
Chinese, for example?).  Of course, a standard or convention
could be used for embedding processing comments in the content,
but that requires having the content available (would you want to
download a 10 MB file only to find out that you cannot use it?).
A Content-Type field parameter is available when the media
itself is not (via HTTP negotiation, via message/external-body,
etc., and can be used to make decisions about retrieval).
Information in the Content-Type field provides metadata for the
media content, and can be stored in a database entry for the
media content (some computer operating systems have such a
facility for storing metadata for files).  The specific parameters
defined for this specific media type constitute such metadata
which can be stored and retrieved by that general mechanism.
>From [email-masked]  Tue Apr 19 18:30:37 2005
From: blilly at erols.com (Bruce Lilly)
Date: Tue Apr 19 18:30:50 2005
Subject: regarding your comments on proposed media type text/troff'
	toInformational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Larry,

Thanks for your comments.

On Mon April 18 2005 15:06, Larry Masinter wrote:
> How about removing the "process" parameter and instead suggesting that
> instructions be included in the source document, in a comment,
> explaining how to process the document, including possible
> recommended command lines, environment variables, preprocessors,
> warnings.

The draft does note that it is possible to include such information
in comments, and cautions against conflicting information.

> Make it explicit that there is no standard format for such
> instructions,

That's one of the problems for authors and recipients.

> and that receivers of text/troff documents should 
> not attempt to try to automatically interpret such instructions
> because instructions might vary widely in format, language,
> and syntax, or contain preconditions or warnings or other
> information.

The more important reason to avoid automatic interpretation is that
is is unsafe to do so.

> It would even be reasonable to suggest, to the creators
> of text/troff content, the complete set of information
> that would be required in such instructions, and even
> some useful guidelines about how to write them in a way
> that others will have good luck interpreting them.
> But by not creating a standard syntax, you will avoid
> encouraging writers of receivers to build automatic
> launch information.

One problem with not having standard syntax is that it may be
impossible for a recipient to understand prose instructions
(would you be able to comprehend instructions in Arabic or
Chinese, for example?).  Of course, a standard or convention
could be used for embedding processing comments in the content,
but that requires having the content available (would you want to
download a 10 MB file only to find out that you cannot use it?).
A Content-Type field parameter is available when the media
itself is not (via HTTP negotiation, via message/external-body,
etc., and can be used to make decisions about retrieval).
Information in the Content-Type field provides metadata for the
media content, and can be stored in a database entry for the
media content (some computer operating systems have such a
facility for storing metadata for files).  The specific parameters
defined for this specific media type constitute such metadata
which can be stored and retrieved by that general mechanism.
>From [email-masked]  Tue Apr 19 19:13:11 2005
From: moore at cs.utk.edu (Keith Moore)
Date: Tue Apr 19 19:13:18 2005
Subject: regarding your comments on proposed media type text/troff' to
 Informational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Bruce,

I've already cited the relevant text, and given you several reasons why
this proposal is not acceptable.  Other people have also objected to
the proposal for the same reasons.  

The process parameter as you have defined it is not an essential part 
of this content-type.  Nor is it likely to be used in the way you assume,
because (as I have already said twice) content-type parameters are 
rarely displayed to recipients.   Nor is the parameter as you have defined
it portable to different implementations of troff that have different 
options.  This parameter is just poorly designed, and it's a security
risk, and there's simply not enough justification for it to be defined
the way you propose.

From: blilly at erols.com (Bruce Lilly)
Date: Tue Jan  3 16:22:59 2006
Subject: regarding your comments on proposed media type text/troff' toInformational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Larry,

Thanks for your comments.

On Mon April 18 2005 15:06, Larry Masinter wrote:
> How about removing the "process" parameter and instead suggesting that
> instructions be included in the source document, in a comment,
> explaining how to process the document, including possible
> recommended command lines, environment variables, preprocessors,
> warnings.

The draft does note that it is possible to include such information
in comments, and cautions against conflicting information.

> Make it explicit that there is no standard format for such
> instructions,

That's one of the problems for authors and recipients.

> and that receivers of text/troff documents should 
> not attempt to try to automatically interpret such instructions
> because instructions might vary widely in format, language,
> and syntax, or contain preconditions or warnings or other
> information.

The more important reason to avoid automatic interpretation is that
is is unsafe to do so.

> It would even be reasonable to suggest, to the creators
> of text/troff content, the complete set of information
> that would be required in such instructions, and even
> some useful guidelines about how to write them in a way
> that others will have good luck interpreting them.
> But by not creating a standard syntax, you will avoid
> encouraging writers of receivers to build automatic
> launch information.

One problem with not having standard syntax is that it may be
impossible for a recipient to understand prose instructions
(would you be able to comprehend instructions in Arabic or
Chinese, for example?).  Of course, a standard or convention
could be used for embedding processing comments in the content,
but that requires having the content available (would you want to
download a 10 MB file only to find out that you cannot use it?).
A Content-Type field parameter is available when the media
itself is not (via HTTP negotiation, via message/external-body,
etc., and can be used to make decisions about retrieval).
Information in the Content-Type field provides metadata for the
media content, and can be stored in a database entry for the
media content (some computer operating systems have such a
facility for storing metadata for files).  The specific parameters
defined for this specific media type constitute such metadata
which can be stored and retrieved by that general mechanism.

From: blilly at erols.com (Bruce Lilly)
Date: Tue Jan  3 16:22:59 2006
Subject: regarding your comments on proposed media type text/troff' toInformational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Larry,

Thanks for your comments.

On Mon April 18 2005 15:06, Larry Masinter wrote:
> How about removing the "process" parameter and instead suggesting that
> instructions be included in the source document, in a comment,
> explaining how to process the document, including possible
> recommended command lines, environment variables, preprocessors,
> warnings.

The draft does note that it is possible to include such information
in comments, and cautions against conflicting information.

> Make it explicit that there is no standard format for such
> instructions,

That's one of the problems for authors and recipients.

> and that receivers of text/troff documents should 
> not attempt to try to automatically interpret such instructions
> because instructions might vary widely in format, language,
> and syntax, or contain preconditions or warnings or other
> information.

The more important reason to avoid automatic interpretation is that
is is unsafe to do so.

> It would even be reasonable to suggest, to the creators
> of text/troff content, the complete set of information
> that would be required in such instructions, and even
> some useful guidelines about how to write them in a way
> that others will have good luck interpreting them.
> But by not creating a standard syntax, you will avoid
> encouraging writers of receivers to build automatic
> launch information.

One problem with not having standard syntax is that it may be
impossible for a recipient to understand prose instructions
(would you be able to comprehend instructions in Arabic or
Chinese, for example?).  Of course, a standard or convention
could be used for embedding processing comments in the content,
but that requires having the content available (would you want to
download a 10 MB file only to find out that you cannot use it?).
A Content-Type field parameter is available when the media
itself is not (via HTTP negotiation, via message/external-body,
etc., and can be used to make decisions about retrieval).
Information in the Content-Type field provides metadata for the
media content, and can be stored in a database entry for the
media content (some computer operating systems have such a
facility for storing metadata for files).  The specific parameters
defined for this specific media type constitute such metadata
which can be stored and retrieved by that general mechanism.

From: LMM at acm.org (Larry Masinter)
Date: Tue Apr 19 18:24:36 2005
Subject: regarding your comments on proposed media type text/troff' toInformational RFC
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

I wish you would reply and say why you think your proposal
(put processing instructions in a parameter) is better than
what I recently proposed as an alternative (put processing
instructions in a comment in the body).

MIME parameters tend to get lost when the MIME bodies are
pushed through most file systems. MIME parameters are hard
to set up for HTTP servers; it's difficult to configure
them to emit widely variable processing instructions, e.g.,
if you were to have several different text/troff files,
each with different processing instructions.

If don't REALLY intend for the processing instructions to be
handled automatically, and you REALLY intend for humans to read
and interpret them, you're better off bundling them inside
the body anyway.

Larry
-- 
http://larry.masinter.net

From: LMM at acm.org (Larry Masinter)
Date: Tue Jan  3 16:22:58 2006
Subject: regarding your comments on proposed media type text/troff' toInformational RFC
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

I wish you would reply and say why you think your proposal
(put processing instructions in a parameter) is better than
what I recently proposed as an alternative (put processing
instructions in a comment in the body).

MIME parameters tend to get lost when the MIME bodies are
pushed through most file systems. MIME parameters are hard
to set up for HTTP servers; it's difficult to configure
them to emit widely variable processing instructions, e.g.,
if you were to have several different text/troff files,
each with different processing instructions.

If don't REALLY intend for the processing instructions to be
handled automatically, and you REALLY intend for humans to read
and interpret them, you're better off bundling them inside
the body anyway.

Larry
-- 
http://larry.masinter.net

From: LMM at acm.org (Larry Masinter)
Date: Tue Jan  3 16:22:58 2006
Subject: regarding your comments on proposed media type text/troff' toInformational RFC
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

I wish you would reply and say why you think your proposal
(put processing instructions in a parameter) is better than
what I recently proposed as an alternative (put processing
instructions in a comment in the body).

MIME parameters tend to get lost when the MIME bodies are
pushed through most file systems. MIME parameters are hard
to set up for HTTP servers; it's difficult to configure
them to emit widely variable processing instructions, e.g.,
if you were to have several different text/troff files,
each with different processing instructions.

If don't REALLY intend for the processing instructions to be
handled automatically, and you REALLY intend for humans to read
and interpret them, you're better off bundling them inside
the body anyway.

Larry
-- 
http://larry.masinter.net

From: blilly at erols.com (Bruce Lilly)
Date: Tue Apr 19 18:01:59 2005
Subject: regarding your comments on proposed media type text/troff' to Informational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Sat April 16 2005 18:46, Keith Moore wrote:
> Bruce,
> 
> bottom line - this parameter violates both the intent and the wording 
> of the MIME spec.  it's simply unacceptable.
> solve the problem in a different way.

I'm not going to engage in speculation regarding "intent".

Regarding the wording in the core MIME RFCs (2045, 2046, 2048, 2049;
2047 is not applicable), the only remotely applicable text that I can
see is in RFC 2048:

   New parameters must not be defined as a way to introduce new
   functionality in types registered in the IETF tree, although new
   parameters may be added to convey additional information that does
   not otherwise change existing functionality.  An example of this
   would be a "revision" parameter to indicate a revision level of an
   external specification such as JPEG.  Similar behavior is encouraged
   for media types registered in the vendor or personal trees but is not
   required.

RFC 2048 is about to be updated; the corresponding text from the most
recent draft is:

   New parameters SHOULD NOT be defined as a way to introduce new
   functionality in types registered in the standards tree, although new
   parameters MAY be added to convey additional information that does
   not otherwise change existing functionality.  An example of this
   would be a "revision" parameter to indicate a revision level of an
   external specification such as JPEG.  Similar behavior is encouraged
   for media types registered in the vendor or personal trees but is not
   required.

The use of BCP 14 keywords clarifies the meaning of the text.  Regarding
that text, no new functionality is introduced by the "process" parameter;
it is added to convey additional information that does not otherwise
change existing functionality.

Absent a specific citation to an applicable section of one of the MIME
RFCs, I'm not inclined to make changes other than clarification that
the usage is strictly end-to-end, user-to-user communication and to
reaffirm the prohibition against automated use for program execution.
>From [email-masked]  Tue Apr 19 18:01:33 2005
From: blilly at erols.com (Bruce Lilly)
Date: Tue Apr 19 18:02:04 2005
Subject: regarding your comments on proposed media type text/troff' to
	Informational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Sat April 16 2005 18:46, Keith Moore wrote:
> Bruce,
> 
> bottom line - this parameter violates both the intent and the wording 
> of the MIME spec.  it's simply unacceptable.
> solve the problem in a different way.

I'm not going to engage in speculation regarding "intent".

Regarding the wording in the core MIME RFCs (2045, 2046, 2048, 2049;
2047 is not applicable), the only remotely applicable text that I can
see is in RFC 2048:

   New parameters must not be defined as a way to introduce new
   functionality in types registered in the IETF tree, although new
   parameters may be added to convey additional information that does
   not otherwise change existing functionality.  An example of this
   would be a "revision" parameter to indicate a revision level of an
   external specification such as JPEG.  Similar behavior is encouraged
   for media types registered in the vendor or personal trees but is not
   required.

RFC 2048 is about to be updated; the corresponding text from the most
recent draft is:

   New parameters SHOULD NOT be defined as a way to introduce new
   functionality in types registered in the standards tree, although new
   parameters MAY be added to convey additional information that does
   not otherwise change existing functionality.  An example of this
   would be a "revision" parameter to indicate a revision level of an
   external specification such as JPEG.  Similar behavior is encouraged
   for media types registered in the vendor or personal trees but is not
   required.

The use of BCP 14 keywords clarifies the meaning of the text.  Regarding
that text, no new functionality is introduced by the "process" parameter;
it is added to convey additional information that does not otherwise
change existing functionality.

Absent a specific citation to an applicable section of one of the MIME
RFCs, I'm not inclined to make changes other than clarification that
the usage is strictly end-to-end, user-to-user communication and to
reaffirm the prohibition against automated use for program execution.
>From [email-masked]  Tue Apr 19 18:24:20 2005
From: LMM at acm.org (Larry Masinter)
Date: Tue Apr 19 18:24:32 2005
Subject: regarding your comments on proposed media type text/troff'
 toInformational RFC
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

I wish you would reply and say why you think your proposal
(put processing instructions in a parameter) is better than
what I recently proposed as an alternative (put processing
instructions in a comment in the body).

MIME parameters tend to get lost when the MIME bodies are
pushed through most file systems. MIME parameters are hard
to set up for HTTP servers; it's difficult to configure
them to emit widely variable processing instructions, e.g.,
if you were to have several different text/troff files,
each with different processing instructions.

If don't REALLY intend for the processing instructions to be
handled automatically, and you REALLY intend for humans to read
and interpret them, you're better off bundling them inside
the body anyway.

Larry
-- 
http://larry.masinter.net

From: blilly at erols.com (Bruce Lilly)
Date: Tue Jan  3 16:22:58 2006
Subject: regarding your comments on proposed media type text/troff' to Informational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Sat April 16 2005 18:46, Keith Moore wrote:
> Bruce,
> 
> bottom line - this parameter violates both the intent and the wording 
> of the MIME spec.  it's simply unacceptable.
> solve the problem in a different way.

I'm not going to engage in speculation regarding "intent".

Regarding the wording in the core MIME RFCs (2045, 2046, 2048, 2049;
2047 is not applicable), the only remotely applicable text that I can
see is in RFC 2048:

   New parameters must not be defined as a way to introduce new
   functionality in types registered in the IETF tree, although new
   parameters may be added to convey additional information that does
   not otherwise change existing functionality.  An example of this
   would be a "revision" parameter to indicate a revision level of an
   external specification such as JPEG.  Similar behavior is encouraged
   for media types registered in the vendor or personal trees but is not
   required.

RFC 2048 is about to be updated; the corresponding text from the most
recent draft is:

   New parameters SHOULD NOT be defined as a way to introduce new
   functionality in types registered in the standards tree, although new
   parameters MAY be added to convey additional information that does
   not otherwise change existing functionality.  An example of this
   would be a "revision" parameter to indicate a revision level of an
   external specification such as JPEG.  Similar behavior is encouraged
   for media types registered in the vendor or personal trees but is not
   required.

The use of BCP 14 keywords clarifies the meaning of the text.  Regarding
that text, no new functionality is introduced by the "process" parameter;
it is added to convey additional information that does not otherwise
change existing functionality.

Absent a specific citation to an applicable section of one of the MIME
RFCs, I'm not inclined to make changes other than clarification that
the usage is strictly end-to-end, user-to-user communication and to
reaffirm the prohibition against automated use for program execution.

From: blilly at erols.com (Bruce Lilly)
Date: Tue Jan  3 16:22:58 2006
Subject: regarding your comments on proposed media type text/troff' to Informational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Sat April 16 2005 18:46, Keith Moore wrote:
> Bruce,
> 
> bottom line - this parameter violates both the intent and the wording 
> of the MIME spec.  it's simply unacceptable.
> solve the problem in a different way.

I'm not going to engage in speculation regarding "intent".

Regarding the wording in the core MIME RFCs (2045, 2046, 2048, 2049;
2047 is not applicable), the only remotely applicable text that I can
see is in RFC 2048:

   New parameters must not be defined as a way to introduce new
   functionality in types registered in the IETF tree, although new
   parameters may be added to convey additional information that does
   not otherwise change existing functionality.  An example of this
   would be a "revision" parameter to indicate a revision level of an
   external specification such as JPEG.  Similar behavior is encouraged
   for media types registered in the vendor or personal trees but is not
   required.

RFC 2048 is about to be updated; the corresponding text from the most
recent draft is:

   New parameters SHOULD NOT be defined as a way to introduce new
   functionality in types registered in the standards tree, although new
   parameters MAY be added to convey additional information that does
   not otherwise change existing functionality.  An example of this
   would be a "revision" parameter to indicate a revision level of an
   external specification such as JPEG.  Similar behavior is encouraged
   for media types registered in the vendor or personal trees but is not
   required.

The use of BCP 14 keywords clarifies the meaning of the text.  Regarding
that text, no new functionality is introduced by the "process" parameter;
it is added to convey additional information that does not otherwise
change existing functionality.

Absent a specific citation to an applicable section of one of the MIME
RFCs, I'm not inclined to make changes other than clarification that
the usage is strictly end-to-end, user-to-user communication and to
reaffirm the prohibition against automated use for program execution.

From: LMM at acm.org (Larry Masinter)
Date: Mon Apr 18 21:07:25 2005
Subject: regarding your comments on proposed media type text/troff' toInformational RFC
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

How about removing the "process" parameter and instead suggesting that
instructions be included in the source document, in a comment,
explaining how to process the document, including possible
recommended command lines, environment variables, preprocessors,
warnings.

Make it explicit that there is no standard format for such
instructions, and that receivers of text/troff documents should
not attempt to try to automatically interpret such instructions
because instructions might vary widely in format, language,
and syntax, or contain preconditions or warnings or other
information.

It would even be reasonable to suggest, to the creators
of text/troff content, the complete set of information
that would be required in such instructions, and even
some useful guidelines about how to write them in a way
that others will have good luck interpreting them.
But by not creating a standard syntax, you will avoid
encouraging writers of receivers to build automatic
launch information.

Larry

From: LMM at acm.org (Larry Masinter)
Date: Tue Jan  3 16:22:58 2006
Subject: regarding your comments on proposed media type text/troff' toInformational RFC
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

How about removing the "process" parameter and instead suggesting that
instructions be included in the source document, in a comment,
explaining how to process the document, including possible
recommended command lines, environment variables, preprocessors,
warnings.

Make it explicit that there is no standard format for such
instructions, and that receivers of text/troff documents should
not attempt to try to automatically interpret such instructions
because instructions might vary widely in format, language,
and syntax, or contain preconditions or warnings or other
information.

It would even be reasonable to suggest, to the creators
of text/troff content, the complete set of information
that would be required in such instructions, and even
some useful guidelines about how to write them in a way
that others will have good luck interpreting them.
But by not creating a standard syntax, you will avoid
encouraging writers of receivers to build automatic
launch information.

Larry

From: moore at cs.utk.edu (Keith Moore)
Date: Sun Apr 17 00:46:50 2005
Subject: regarding your comments on proposed media type text/troff' to Informational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Bruce,

bottom line - this parameter violates both the intent and the wording 
of the MIME spec.  it's simply unacceptable.
solve the problem in a different way.

Keith

On Apr 16, 2005, at 11:12 AM, Bruce Lilly wrote:

> On Fri April 15 2005 10:36, Keith Moore wrote:
>
>> And you dismissed the objections that other people raised about this
>> very issue on that list.
>
> No, wording of the draft was changed as a result.
>
>>> The "process" parameter is explicitly *NOT* "giving the sender a way
>>> to choose what program to run on the recipient's system".  It is a 
>>> way
>>> for the sender to suggest a recommended processing sequence to the
>>> human recipient.  N.B. "suggest", "recommended", and "human".
>>
>> It's a distinction without a practical difference.
>
> No, if some wayward implementer were to automatically execute programs
> contrary to the specification, said implementer can be informed that he
> is out of line.  That is a very real "practical difference" between the
> actual draft and your mischaracterization of what the draft says.  You
> seem to:
> a) want to remove any standardized mechanism for the author to convey
>    relevant information to the recipient
> b) believe that groff can magically determine preprocessors, an
>    appropriate ordering of preprocessors with appropriate arguments,
>    etc.
> Removal of the "process" parameter will not prevent a wayward 
> implementer
> from simply automatically invoking groff; removal of the parameter
> therefore will not address inappropriate use of the media type and
> metadata, and removal of discussion of inappropriate use of said 
> parameter
> along with its specification would leave no stick with which to educate
> such implementers.  It will, however, impair legitimate uses of the 
> media
> type and metadata.
>
>> There have been similar recommendations in every version of the MIME
>> spec. Guess what?  They were consistently ignored by major vendors.
>> Running code and hundreds of billions of dollars worth of damage due 
>> to
>> viruses  aptly demonstrates that even though the spec says "don't
>> present executable content" implementations will do it anyway.
>
> Don't blame me for inappropriate behavior of some unrelated vendor. If
> multiple recommendations haven't prevented inappropriate 
> implementations,
> what leads you to the conclusion that failing to make recommendations
> will improve matters?
>
>> The
>> process parameter is executable content.
>
> No, it's a human-writable, human-readable hint in a well-understood,
> precise, concise, standardized (e.g. POSIX) format.
>
>>> The intent is to specify the preprocessors and parameters which will
>>> produce the output that the author intended, not arbitrary progams/
>>> parameters.
>>
>> If the author wants to enclose a Makefile or build script as a 
>> separate
>> text/plain attachment, he's free to do so.
>
> You seem to be fixated on a niche application of media types, which are
> being separated from the mail environment.  In general, there is 
> nothing
> in which to "enclose" separate content, or to which to make an
> "attachment".  Consider, as an example of possible use outside of a 
> mail
> environment, a means of recording such metadata in some sort of 
> database
> with entries for files (e.g. similar to a MacOS "resource fork", or the
> comments field which can be set for files in recent versions of MS
> Windows).
>
> Moreover, a "build script" would fit into the category of "languages 
> for
> 'active' (computational) material", which is the application media 
> type,
> not text, and certainly not text/plain.  See
> draft-freed-media-type-reg-04.txt.
>
>> It's a lousy way to do that.  Parameters are typically not displayed 
>> to
>> the recipient.  They're either interpreted my the MUA or ignored.
>
> Again, you're fixated on a mail environment, which is not the only
> application for media types.
>
>> Let me get this straight.
>
> OK, I'll try to clarify the situation.
>
>> First you argue that the process parameter
>> isn't intended to be executed,
>
> Not intended to be automatically executed.  If the human recipient,
> after exercising due caution, wishes to follow the suggestion supplied
> by the content author, he is of course free to do so -- or he can
> execute some other, possibly similar set of processes, or he can choose
> not to format the content.
>
>> and then you argue that a different kind
>> of parameter that only specified the preprocessors to be used would
>> not be appropriate because _it_ couldn't be executed?
>
> No, the objections to a mere unordered list of preprocessors includes:
>
> 1. preprocessor order is critically important
> 2. preprocessor arguments are critically important
> 3. environment variables (e.g. GROFF_NO_SGR in recent groff versions)
>    may be critically important
> 4. formatter arguments are critically important
> 5. postprocessing may be required
>
> Your suggestion addresses none of those issues, all of which are
> accommodated by command-line syntax.  Moreover:
>
> I. command-line syntax is easy for an author to indicate, with 
> precision
>    and conciseness
> II. command-line syntax can be read, understood, modified if desired,
>    and used by recipients.
>
> A mere list lacks those characteristics.  Obfuscating processing steps
> by some sort of mechanical translation of easily-generated, easily-read
> syntax adds extra manual, error-prone steps for both author and 
> recipient,
> but will not slow down a wayward implementer who is determined to
> automatically pass content to a program; he'll simply automate the
> translation.  That would have precisely the opposite effect of the
> current wording of the draft; it would make legitimate use difficult
> while making automated misuse straightforward.
>
>> And then you're arguing that the purpose of the process parameter
>> isn't to specify arbitrary code to be executed,
>
> Correct.
>
>> but you also admit
>> that there's no clearly defined set of preprocessors for troff?
>
> No, at any given time, one can enumerate a set of preprocessors, as has
> been done in the registration template in the draft under discussion --
> but that set may change over time as new preprocessors are developed.
> One can clearly define a set of preprocessors as programs with the
> following characteristics:
>
> i. the program operates as a filter, accepting input and producing
>    output (as opposed to programs which do not do both, such as "ls",
>    etc.)
> ii. The input and output formats conform to troff format conventions as
>    specified in CSTR 54, e.g. directives intermixed with text, 
> directives
>    begin with dot, etc.
> iii. input is human-readable content describing some abstract format
>    which is translated into formatting directives or to another human-
>    readable format for further processing with the ultimate goal being
>    production of formatted output
> iv. the input to be preprocessed is delimited by specified directives,
>    and other input is passed to the output unaltered (so the programs
>    in the graphviz suite, which can generate pic output, do not
>    qualify as preprocessors because they do not accept/pass other
>    input).
>
>> If there's no clearly defined set, it's arbitrary.
>
> There is a clearly defined set; see above for a definition.
>
>>>> The Version 7
>>>> UNIX versions of these tools (circa 1979) described in the "CSTR 49"
>>>> document you cite had several limitations (many related to having to
>>>> run in 64k of code space on a pdp 11/70), that don't apply to modern
>>>> troff implementations.
>>>
>>> How is that relevant?  The CSTR documents have been updated.
>>
>> Some of the problems with ordering of preprocessors had to do with 
>> some
>> preprocessors running out of memory if earlier preprocessors generated
>> lots of output.
>
> While that might be relevant to a recipient with a particular legacy
> implementation, it is not relevant for the purpose of describing the
> preprocessors, their order, their arguments, and environment settings
> necessary for successful formatting of particular content.
>
>> So design a parameter that specifies ordering without specifying the
>> command-line.
>
> See above reasons why that would be harmful to the intended use for
> end-to-end, human-to-human communications intended for the parameter,
> and why it would not deter determined but wayward implementers.
>
>> The reality is that in practice troff isn't a single data format, it's
>> a lot of fairlly arbitrary variations on a format.
>
> Not arbitrary.
>
>> For this reason,
>> it doesn't lend itself to easy MIME typing.
>
> As mentioned in the draft, some specific instances of content might be
> more appropriately categorized under the image or application media
> types.  The draft explicitly does not address those cases.
>
>> So specifying a sane
>> MIME type for troff is a harder problem than it initially seems,
>> and you're running into that.
>
> No, there's no particular difficulty in specifying the format for
> text use.  Your complaints seem to boil down to implementers who
> ignore existing recommendations which are reinforced in the draft
> under discussion.  Nothing that can be said in this particular draft
> is likely to change that for this media type or any other -- idiotic
> implementers are what they are.  Making media types more difficult for
> legitimate, conscientious users to use on the groundless assumption
> that that will cause determined wayward implementers to see the light
> smacks of a "nanny" or "Big Brother is Watching You" approach.

From: moore at cs.utk.edu (Keith Moore)
Date: Tue Jan  3 16:22:58 2006
Subject: regarding your comments on proposed media type text/troff' to Informational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Bruce,

bottom line - this parameter violates both the intent and the wording 
of the MIME spec.  it's simply unacceptable.
solve the problem in a different way.

Keith

On Apr 16, 2005, at 11:12 AM, Bruce Lilly wrote:

> On Fri April 15 2005 10:36, Keith Moore wrote:
>
>> And you dismissed the objections that other people raised about this
>> very issue on that list.
>
> No, wording of the draft was changed as a result.
>
>>> The "process" parameter is explicitly *NOT* "giving the sender a way
>>> to choose what program to run on the recipient's system".  It is a 
>>> way
>>> for the sender to suggest a recommended processing sequence to the
>>> human recipient.  N.B. "suggest", "recommended", and "human".
>>
>> It's a distinction without a practical difference.
>
> No, if some wayward implementer were to automatically execute programs
> contrary to the specification, said implementer can be informed that he
> is out of line.  That is a very real "practical difference" between the
> actual draft and your mischaracterization of what the draft says.  You
> seem to:
> a) want to remove any standardized mechanism for the author to convey
>    relevant information to the recipient
> b) believe that groff can magically determine preprocessors, an
>    appropriate ordering of preprocessors with appropriate arguments,
>    etc.
> Removal of the "process" parameter will not prevent a wayward 
> implementer
> from simply automatically invoking groff; removal of the parameter
> therefore will not address inappropriate use of the media type and
> metadata, and removal of discussion of inappropriate use of said 
> parameter
> along with its specification would leave no stick with which to educate
> such implementers.  It will, however, impair legitimate uses of the 
> media
> type and metadata.
>
>> There have been similar recommendations in every version of the MIME
>> spec. Guess what?  They were consistently ignored by major vendors.
>> Running code and hundreds of billions of dollars worth of damage due 
>> to
>> viruses  aptly demonstrates that even though the spec says "don't
>> present executable content" implementations will do it anyway.
>
> Don't blame me for inappropriate behavior of some unrelated vendor. If
> multiple recommendations haven't prevented inappropriate 
> implementations,
> what leads you to the conclusion that failing to make recommendations
> will improve matters?
>
>> The
>> process parameter is executable content.
>
> No, it's a human-writable, human-readable hint in a well-understood,
> precise, concise, standardized (e.g. POSIX) format.
>
>>> The intent is to specify the preprocessors and parameters which will
>>> produce the output that the author intended, not arbitrary progams/
>>> parameters.
>>
>> If the author wants to enclose a Makefile or build script as a 
>> separate
>> text/plain attachment, he's free to do so.
>
> You seem to be fixated on a niche application of media types, which are
> being separated from the mail environment.  In general, there is 
> nothing
> in which to "enclose" separate content, or to which to make an
> "attachment".  Consider, as an example of possible use outside of a 
> mail
> environment, a means of recording such metadata in some sort of 
> database
> with entries for files (e.g. similar to a MacOS "resource fork", or the
> comments field which can be set for files in recent versions of MS
> Windows).
>
> Moreover, a "build script" would fit into the category of "languages 
> for
> 'active' (computational) material", which is the application media 
> type,
> not text, and certainly not text/plain.  See
> draft-freed-media-type-reg-04.txt.
>
>> It's a lousy way to do that.  Parameters are typically not displayed 
>> to
>> the recipient.  They're either interpreted my the MUA or ignored.
>
> Again, you're fixated on a mail environment, which is not the only
> application for media types.
>
>> Let me get this straight.
>
> OK, I'll try to clarify the situation.
>
>> First you argue that the process parameter
>> isn't intended to be executed,
>
> Not intended to be automatically executed.  If the human recipient,
> after exercising due caution, wishes to follow the suggestion supplied
> by the content author, he is of course free to do so -- or he can
> execute some other, possibly similar set of processes, or he can choose
> not to format the content.
>
>> and then you argue that a different kind
>> of parameter that only specified the preprocessors to be used would
>> not be appropriate because _it_ couldn't be executed?
>
> No, the objections to a mere unordered list of preprocessors includes:
>
> 1. preprocessor order is critically important
> 2. preprocessor arguments are critically important
> 3. environment variables (e.g. GROFF_NO_SGR in recent groff versions)
>    may be critically important
> 4. formatter arguments are critically important
> 5. postprocessing may be required
>
> Your suggestion addresses none of those issues, all of which are
> accommodated by command-line syntax.  Moreover:
>
> I. command-line syntax is easy for an author to indicate, with 
> precision
>    and conciseness
> II. command-line syntax can be read, understood, modified if desired,
>    and used by recipients.
>
> A mere list lacks those characteristics.  Obfuscating processing steps
> by some sort of mechanical translation of easily-generated, easily-read
> syntax adds extra manual, error-prone steps for both author and 
> recipient,
> but will not slow down a wayward implementer who is determined to
> automatically pass content to a program; he'll simply automate the
> translation.  That would have precisely the opposite effect of the
> current wording of the draft; it would make legitimate use difficult
> while making automated misuse straightforward.
>
>> And then you're arguing that the purpose of the process parameter
>> isn't to specify arbitrary code to be executed,
>
> Correct.
>
>> but you also admit
>> that there's no clearly defined set of preprocessors for troff?
>
> No, at any given time, one can enumerate a set of preprocessors, as has
> been done in the registration template in the draft under discussion --
> but that set may change over time as new preprocessors are developed.
> One can clearly define a set of preprocessors as programs with the
> following characteristics:
>
> i. the program operates as a filter, accepting input and producing
>    output (as opposed to programs which do not do both, such as "ls",
>    etc.)
> ii. The input and output formats conform to troff format conventions as
>    specified in CSTR 54, e.g. directives intermixed with text, 
> directives
>    begin with dot, etc.
> iii. input is human-readable content describing some abstract format
>    which is translated into formatting directives or to another human-
>    readable format for further processing with the ultimate goal being
>    production of formatted output
> iv. the input to be preprocessed is delimited by specified directives,
>    and other input is passed to the output unaltered (so the programs
>    in the graphviz suite, which can generate pic output, do not
>    qualify as preprocessors because they do not accept/pass other
>    input).
>
>> If there's no clearly defined set, it's arbitrary.
>
> There is a clearly defined set; see above for a definition.
>
>>>> The Version 7
>>>> UNIX versions of these tools (circa 1979) described in the "CSTR 49"
>>>> document you cite had several limitations (many related to having to
>>>> run in 64k of code space on a pdp 11/70), that don't apply to modern
>>>> troff implementations.
>>>
>>> How is that relevant?  The CSTR documents have been updated.
>>
>> Some of the problems with ordering of preprocessors had to do with 
>> some
>> preprocessors running out of memory if earlier preprocessors generated
>> lots of output.
>
> While that might be relevant to a recipient with a particular legacy
> implementation, it is not relevant for the purpose of describing the
> preprocessors, their order, their arguments, and environment settings
> necessary for successful formatting of particular content.
>
>> So design a parameter that specifies ordering without specifying the
>> command-line.
>
> See above reasons why that would be harmful to the intended use for
> end-to-end, human-to-human communications intended for the parameter,
> and why it would not deter determined but wayward implementers.
>
>> The reality is that in practice troff isn't a single data format, it's
>> a lot of fairlly arbitrary variations on a format.
>
> Not arbitrary.
>
>> For this reason,
>> it doesn't lend itself to easy MIME typing.
>
> As mentioned in the draft, some specific instances of content might be
> more appropriately categorized under the image or application media
> types.  The draft explicitly does not address those cases.
>
>> So specifying a sane
>> MIME type for troff is a harder problem than it initially seems,
>> and you're running into that.
>
> No, there's no particular difficulty in specifying the format for
> text use.  Your complaints seem to boil down to implementers who
> ignore existing recommendations which are reinforced in the draft
> under discussion.  Nothing that can be said in this particular draft
> is likely to change that for this media type or any other -- idiotic
> implementers are what they are.  Making media types more difficult for
> legitimate, conscientious users to use on the groundless assumption
> that that will cause determined wayward implementers to see the light
> smacks of a "nanny" or "Big Brother is Watching You" approach.

From: moore at cs.utk.edu (Keith Moore)
Date: Tue Jan  3 16:22:58 2006
Subject: regarding your comments on proposed media type text/troff' to Informational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Bruce,

bottom line - this parameter violates both the intent and the wording 
of the MIME spec.  it's simply unacceptable.
solve the problem in a different way.

Keith

On Apr 16, 2005, at 11:12 AM, Bruce Lilly wrote:

> On Fri April 15 2005 10:36, Keith Moore wrote:
>
>> And you dismissed the objections that other people raised about this
>> very issue on that list.
>
> No, wording of the draft was changed as a result.
>
>>> The "process" parameter is explicitly *NOT* "giving the sender a way
>>> to choose what program to run on the recipient's system".  It is a 
>>> way
>>> for the sender to suggest a recommended processing sequence to the
>>> human recipient.  N.B. "suggest", "recommended", and "human".
>>
>> It's a distinction without a practical difference.
>
> No, if some wayward implementer were to automatically execute programs
> contrary to the specification, said implementer can be informed that he
> is out of line.  That is a very real "practical difference" between the
> actual draft and your mischaracterization of what the draft says.  You
> seem to:
> a) want to remove any standardized mechanism for the author to convey
>    relevant information to the recipient
> b) believe that groff can magically determine preprocessors, an
>    appropriate ordering of preprocessors with appropriate arguments,
>    etc.
> Removal of the "process" parameter will not prevent a wayward 
> implementer
> from simply automatically invoking groff; removal of the parameter
> therefore will not address inappropriate use of the media type and
> metadata, and removal of discussion of inappropriate use of said 
> parameter
> along with its specification would leave no stick with which to educate
> such implementers.  It will, however, impair legitimate uses of the 
> media
> type and metadata.
>
>> There have been similar recommendations in every version of the MIME
>> spec. Guess what?  They were consistently ignored by major vendors.
>> Running code and hundreds of billions of dollars worth of damage due 
>> to
>> viruses  aptly demonstrates that even though the spec says "don't
>> present executable content" implementations will do it anyway.
>
> Don't blame me for inappropriate behavior of some unrelated vendor. If
> multiple recommendations haven't prevented inappropriate 
> implementations,
> what leads you to the conclusion that failing to make recommendations
> will improve matters?
>
>> The
>> process parameter is executable content.
>
> No, it's a human-writable, human-readable hint in a well-understood,
> precise, concise, standardized (e.g. POSIX) format.
>
>>> The intent is to specify the preprocessors and parameters which will
>>> produce the output that the author intended, not arbitrary progams/
>>> parameters.
>>
>> If the author wants to enclose a Makefile or build script as a 
>> separate
>> text/plain attachment, he's free to do so.
>
> You seem to be fixated on a niche application of media types, which are
> being separated from the mail environment.  In general, there is 
> nothing
> in which to "enclose" separate content, or to which to make an
> "attachment".  Consider, as an example of possible use outside of a 
> mail
> environment, a means of recording such metadata in some sort of 
> database
> with entries for files (e.g. similar to a MacOS "resource fork", or the
> comments field which can be set for files in recent versions of MS
> Windows).
>
> Moreover, a "build script" would fit into the category of "languages 
> for
> 'active' (computational) material", which is the application media 
> type,
> not text, and certainly not text/plain.  See
> draft-freed-media-type-reg-04.txt.
>
>> It's a lousy way to do that.  Parameters are typically not displayed 
>> to
>> the recipient.  They're either interpreted my the MUA or ignored.
>
> Again, you're fixated on a mail environment, which is not the only
> application for media types.
>
>> Let me get this straight.
>
> OK, I'll try to clarify the situation.
>
>> First you argue that the process parameter
>> isn't intended to be executed,
>
> Not intended to be automatically executed.  If the human recipient,
> after exercising due caution, wishes to follow the suggestion supplied
> by the content author, he is of course free to do so -- or he can
> execute some other, possibly similar set of processes, or he can choose
> not to format the content.
>
>> and then you argue that a different kind
>> of parameter that only specified the preprocessors to be used would
>> not be appropriate because _it_ couldn't be executed?
>
> No, the objections to a mere unordered list of preprocessors includes:
>
> 1. preprocessor order is critically important
> 2. preprocessor arguments are critically important
> 3. environment variables (e.g. GROFF_NO_SGR in recent groff versions)
>    may be critically important
> 4. formatter arguments are critically important
> 5. postprocessing may be required
>
> Your suggestion addresses none of those issues, all of which are
> accommodated by command-line syntax.  Moreover:
>
> I. command-line syntax is easy for an author to indicate, with 
> precision
>    and conciseness
> II. command-line syntax can be read, understood, modified if desired,
>    and used by recipients.
>
> A mere list lacks those characteristics.  Obfuscating processing steps
> by some sort of mechanical translation of easily-generated, easily-read
> syntax adds extra manual, error-prone steps for both author and 
> recipient,
> but will not slow down a wayward implementer who is determined to
> automatically pass content to a program; he'll simply automate the
> translation.  That would have precisely the opposite effect of the
> current wording of the draft; it would make legitimate use difficult
> while making automated misuse straightforward.
>
>> And then you're arguing that the purpose of the process parameter
>> isn't to specify arbitrary code to be executed,
>
> Correct.
>
>> but you also admit
>> that there's no clearly defined set of preprocessors for troff?
>
> No, at any given time, one can enumerate a set of preprocessors, as has
> been done in the registration template in the draft under discussion --
> but that set may change over time as new preprocessors are developed.
> One can clearly define a set of preprocessors as programs with the
> following characteristics:
>
> i. the program operates as a filter, accepting input and producing
>    output (as opposed to programs which do not do both, such as "ls",
>    etc.)
> ii. The input and output formats conform to troff format conventions as
>    specified in CSTR 54, e.g. directives intermixed with text, 
> directives
>    begin with dot, etc.
> iii. input is human-readable content describing some abstract format
>    which is translated into formatting directives or to another human-
>    readable format for further processing with the ultimate goal being
>    production of formatted output
> iv. the input to be preprocessed is delimited by specified directives,
>    and other input is passed to the output unaltered (so the programs
>    in the graphviz suite, which can generate pic output, do not
>    qualify as preprocessors because they do not accept/pass other
>    input).
>
>> If there's no clearly defined set, it's arbitrary.
>
> There is a clearly defined set; see above for a definition.
>
>>>> The Version 7
>>>> UNIX versions of these tools (circa 1979) described in the "CSTR 49"
>>>> document you cite had several limitations (many related to having to
>>>> run in 64k of code space on a pdp 11/70), that don't apply to modern
>>>> troff implementations.
>>>
>>> How is that relevant?  The CSTR documents have been updated.
>>
>> Some of the problems with ordering of preprocessors had to do with 
>> some
>> preprocessors running out of memory if earlier preprocessors generated
>> lots of output.
>
> While that might be relevant to a recipient with a particular legacy
> implementation, it is not relevant for the purpose of describing the
> preprocessors, their order, their arguments, and environment settings
> necessary for successful formatting of particular content.
>
>> So design a parameter that specifies ordering without specifying the
>> command-line.
>
> See above reasons why that would be harmful to the intended use for
> end-to-end, human-to-human communications intended for the parameter,
> and why it would not deter determined but wayward implementers.
>
>> The reality is that in practice troff isn't a single data format, it's
>> a lot of fairlly arbitrary variations on a format.
>
> Not arbitrary.
>
>> For this reason,
>> it doesn't lend itself to easy MIME typing.
>
> As mentioned in the draft, some specific instances of content might be
> more appropriately categorized under the image or application media
> types.  The draft explicitly does not address those cases.
>
>> So specifying a sane
>> MIME type for troff is a harder problem than it initially seems,
>> and you're running into that.
>
> No, there's no particular difficulty in specifying the format for
> text use.  Your complaints seem to boil down to implementers who
> ignore existing recommendations which are reinforced in the draft
> under discussion.  Nothing that can be said in this particular draft
> is likely to change that for this media type or any other -- idiotic
> implementers are what they are.  Making media types more difficult for
> legitimate, conscientious users to use on the groundless assumption
> that that will cause determined wayward implementers to see the light
> smacks of a "nanny" or "Big Brother is Watching You" approach.

From: blilly at erols.com (Bruce Lilly)
Date: Tue Jan  3 16:22:58 2006
Subject: regarding your comments on proposed media type text/troff' to Informational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Fri April 15 2005 10:36, Keith Moore wrote:

> And you dismissed the objections that other people raised about this
> very issue on that list.

No, wording of the draft was changed as a result.

> > The "process" parameter is explicitly *NOT* "giving the sender a way
> > to choose what program to run on the recipient's system".  It is a way
> > for the sender to suggest a recommended processing sequence to the
> > human recipient.  N.B. "suggest", "recommended", and "human".
> 
> It's a distinction without a practical difference.

No, if some wayward implementer were to automatically execute programs
contrary to the specification, said implementer can be informed that he
is out of line.  That is a very real "practical difference" between the
actual draft and your mischaracterization of what the draft says.  You
seem to:
a) want to remove any standardized mechanism for the author to convey
   relevant information to the recipient
b) believe that groff can magically determine preprocessors, an
   appropriate ordering of preprocessors with appropriate arguments,
   etc.
Removal of the "process" parameter will not prevent a wayward implementer
from simply automatically invoking groff; removal of the parameter
therefore will not address inappropriate use of the media type and
metadata, and removal of discussion of inappropriate use of said parameter
along with its specification would leave no stick with which to educate
such implementers.  It will, however, impair legitimate uses of the media
type and metadata.

> There have been similar recommendations in every version of the MIME
> spec. Guess what?  They were consistently ignored by major vendors. 
> Running code and hundreds of billions of dollars worth of damage due to
> viruses  aptly demonstrates that even though the spec says "don't
> present executable content" implementations will do it anyway.

Don't blame me for inappropriate behavior of some unrelated vendor. If
multiple recommendations haven't prevented inappropriate implementations,
what leads you to the conclusion that failing to make recommendations
will improve matters?

> The 
> process parameter is executable content.

No, it's a human-writable, human-readable hint in a well-understood,
precise, concise, standardized (e.g. POSIX) format.
 
> > The intent is to specify the preprocessors and parameters which will
> > produce the output that the author intended, not arbitrary progams/
> > parameters.  
> 
> If the author wants to enclose a Makefile or build script as a separate
> text/plain attachment, he's free to do so.  

You seem to be fixated on a niche application of media types, which are
being separated from the mail environment.  In general, there is nothing
in which to "enclose" separate content, or to which to make an
"attachment".  Consider, as an example of possible use outside of a mail
environment, a means of recording such metadata in some sort of database
with entries for files (e.g. similar to a MacOS "resource fork", or the
comments field which can be set for files in recent versions of MS
Windows).

Moreover, a "build script" would fit into the category of "languages for
'active' (computational) material", which is the application media type,
not text, and certainly not text/plain.  See
draft-freed-media-type-reg-04.txt.
 
> It's a lousy way to do that.  Parameters are typically not displayed to
> the recipient.  They're either interpreted my the MUA or ignored.

Again, you're fixated on a mail environment, which is not the only
application for media types.
 
> Let me get this straight.

OK, I'll try to clarify the situation.

> First you argue that the process parameter 
> isn't intended to be executed,

Not intended to be automatically executed.  If the human recipient,
after exercising due caution, wishes to follow the suggestion supplied
by the content author, he is of course free to do so -- or he can
execute some other, possibly similar set of processes, or he can choose
not to format the content.

> and then you argue that a different kind 
> of parameter that only specified the preprocessors to be used would 
> not be appropriate because _it_ couldn't be executed?

No, the objections to a mere unordered list of preprocessors includes:

1. preprocessor order is critically important
2. preprocessor arguments are critically important
3. environment variables (e.g. GROFF_NO_SGR in recent groff versions)
   may be critically important
4. formatter arguments are critically important
5. postprocessing may be required

Your suggestion addresses none of those issues, all of which are
accommodated by command-line syntax.  Moreover:

I. command-line syntax is easy for an author to indicate, with precision
   and conciseness
II. command-line syntax can be read, understood, modified if desired,
   and used by recipients.

A mere list lacks those characteristics.  Obfuscating processing steps
by some sort of mechanical translation of easily-generated, easily-read
syntax adds extra manual, error-prone steps for both author and recipient,
but will not slow down a wayward implementer who is determined to
automatically pass content to a program; he'll simply automate the
translation.  That would have precisely the opposite effect of the
current wording of the draft; it would make legitimate use difficult
while making automated misuse straightforward.

> And then you're arguing that the purpose of the process parameter
> isn't to specify arbitrary code to be executed,

Correct.

> but you also admit 
> that there's no clearly defined set of preprocessors for troff?

No, at any given time, one can enumerate a set of preprocessors, as has
been done in the registration template in the draft under discussion --
but that set may change over time as new preprocessors are developed.
One can clearly define a set of preprocessors as programs with the
following characteristics:

i. the program operates as a filter, accepting input and producing
   output (as opposed to programs which do not do both, such as "ls",
   etc.)
ii. The input and output formats conform to troff format conventions as
   specified in CSTR 54, e.g. directives intermixed with text, directives
   begin with dot, etc.
iii. input is human-readable content describing some abstract format
   which is translated into formatting directives or to another human-
   readable format for further processing with the ultimate goal being
   production of formatted output
iv. the input to be preprocessed is delimited by specified directives,
   and other input is passed to the output unaltered (so the programs
   in the graphviz suite, which can generate pic output, do not
   qualify as preprocessors because they do not accept/pass other
   input).

> If there's no clearly defined set, it's arbitrary.

There is a clearly defined set; see above for a definition.
 
> > > The Version 7  
> > > UNIX versions of these tools (circa 1979) described in the "CSTR 49"
> > > document you cite had several limitations (many related to having to
> > > run in 64k of code space on a pdp 11/70), that don't apply to modern
> > > troff implementations.
> > 
> > How is that relevant?  The CSTR documents have been updated.  
> 
> Some of the problems with ordering of preprocessors had to do with some
> preprocessors running out of memory if earlier preprocessors generated
> lots of output.

While that might be relevant to a recipient with a particular legacy
implementation, it is not relevant for the purpose of describing the
preprocessors, their order, their arguments, and environment settings
necessary for successful formatting of particular content.
 
> So design a parameter that specifies ordering without specifying the
> command-line.

See above reasons why that would be harmful to the intended use for
end-to-end, human-to-human communications intended for the parameter,
and why it would not deter determined but wayward implementers.
 
> The reality is that in practice troff isn't a single data format, it's 
> a lot of fairlly arbitrary variations on a format.

Not arbitrary.

> For this reason,  
> it doesn't lend itself to easy MIME typing.

As mentioned in the draft, some specific instances of content might be
more appropriately categorized under the image or application media
types.  The draft explicitly does not address those cases.

> So specifying a sane  
> MIME type for troff is a harder problem than it initially seems, 
> and you're running into that.

No, there's no particular difficulty in specifying the format for
text use.  Your complaints seem to boil down to implementers who
ignore existing recommendations which are reinforced in the draft
under discussion.  Nothing that can be said in this particular draft
is likely to change that for this media type or any other -- idiotic
implementers are what they are.  Making media types more difficult for
legitimate, conscientious users to use on the groundless assumption
that that will cause determined wayward implementers to see the light
smacks of a "nanny" or "Big Brother is Watching You" approach.

From: blilly at erols.com (Bruce Lilly)
Date: Tue Jan  3 16:22:58 2006
Subject: regarding your comments on proposed media type text/troff' to Informational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Fri April 15 2005 10:36, Keith Moore wrote:

> And you dismissed the objections that other people raised about this
> very issue on that list.

No, wording of the draft was changed as a result.

> > The "process" parameter is explicitly *NOT* "giving the sender a way
> > to choose what program to run on the recipient's system".  It is a way
> > for the sender to suggest a recommended processing sequence to the
> > human recipient.  N.B. "suggest", "recommended", and "human".
> 
> It's a distinction without a practical difference.

No, if some wayward implementer were to automatically execute programs
contrary to the specification, said implementer can be informed that he
is out of line.  That is a very real "practical difference" between the
actual draft and your mischaracterization of what the draft says.  You
seem to:
a) want to remove any standardized mechanism for the author to convey
   relevant information to the recipient
b) believe that groff can magically determine preprocessors, an
   appropriate ordering of preprocessors with appropriate arguments,
   etc.
Removal of the "process" parameter will not prevent a wayward implementer
from simply automatically invoking groff; removal of the parameter
therefore will not address inappropriate use of the media type and
metadata, and removal of discussion of inappropriate use of said parameter
along with its specification would leave no stick with which to educate
such implementers.  It will, however, impair legitimate uses of the media
type and metadata.

> There have been similar recommendations in every version of the MIME
> spec. Guess what?  They were consistently ignored by major vendors. 
> Running code and hundreds of billions of dollars worth of damage due to
> viruses  aptly demonstrates that even though the spec says "don't
> present executable content" implementations will do it anyway.

Don't blame me for inappropriate behavior of some unrelated vendor. If
multiple recommendations haven't prevented inappropriate implementations,
what leads you to the conclusion that failing to make recommendations
will improve matters?

> The 
> process parameter is executable content.

No, it's a human-writable, human-readable hint in a well-understood,
precise, concise, standardized (e.g. POSIX) format.
 
> > The intent is to specify the preprocessors and parameters which will
> > produce the output that the author intended, not arbitrary progams/
> > parameters.  
> 
> If the author wants to enclose a Makefile or build script as a separate
> text/plain attachment, he's free to do so.  

You seem to be fixated on a niche application of media types, which are
being separated from the mail environment.  In general, there is nothing
in which to "enclose" separate content, or to which to make an
"attachment".  Consider, as an example of possible use outside of a mail
environment, a means of recording such metadata in some sort of database
with entries for files (e.g. similar to a MacOS "resource fork", or the
comments field which can be set for files in recent versions of MS
Windows).

Moreover, a "build script" would fit into the category of "languages for
'active' (computational) material", which is the application media type,
not text, and certainly not text/plain.  See
draft-freed-media-type-reg-04.txt.
 
> It's a lousy way to do that.  Parameters are typically not displayed to
> the recipient.  They're either interpreted my the MUA or ignored.

Again, you're fixated on a mail environment, which is not the only
application for media types.
 
> Let me get this straight.

OK, I'll try to clarify the situation.

> First you argue that the process parameter 
> isn't intended to be executed,

Not intended to be automatically executed.  If the human recipient,
after exercising due caution, wishes to follow the suggestion supplied
by the content author, he is of course free to do so -- or he can
execute some other, possibly similar set of processes, or he can choose
not to format the content.

> and then you argue that a different kind 
> of parameter that only specified the preprocessors to be used would 
> not be appropriate because _it_ couldn't be executed?

No, the objections to a mere unordered list of preprocessors includes:

1. preprocessor order is critically important
2. preprocessor arguments are critically important
3. environment variables (e.g. GROFF_NO_SGR in recent groff versions)
   may be critically important
4. formatter arguments are critically important
5. postprocessing may be required

Your suggestion addresses none of those issues, all of which are
accommodated by command-line syntax.  Moreover:

I. command-line syntax is easy for an author to indicate, with precision
   and conciseness
II. command-line syntax can be read, understood, modified if desired,
   and used by recipients.

A mere list lacks those characteristics.  Obfuscating processing steps
by some sort of mechanical translation of easily-generated, easily-read
syntax adds extra manual, error-prone steps for both author and recipient,
but will not slow down a wayward implementer who is determined to
automatically pass content to a program; he'll simply automate the
translation.  That would have precisely the opposite effect of the
current wording of the draft; it would make legitimate use difficult
while making automated misuse straightforward.

> And then you're arguing that the purpose of the process parameter
> isn't to specify arbitrary code to be executed,

Correct.

> but you also admit 
> that there's no clearly defined set of preprocessors for troff?

No, at any given time, one can enumerate a set of preprocessors, as has
been done in the registration template in the draft under discussion --
but that set may change over time as new preprocessors are developed.
One can clearly define a set of preprocessors as programs with the
following characteristics:

i. the program operates as a filter, accepting input and producing
   output (as opposed to programs which do not do both, such as "ls",
   etc.)
ii. The input and output formats conform to troff format conventions as
   specified in CSTR 54, e.g. directives intermixed with text, directives
   begin with dot, etc.
iii. input is human-readable content describing some abstract format
   which is translated into formatting directives or to another human-
   readable format for further processing with the ultimate goal being
   production of formatted output
iv. the input to be preprocessed is delimited by specified directives,
   and other input is passed to the output unaltered (so the programs
   in the graphviz suite, which can generate pic output, do not
   qualify as preprocessors because they do not accept/pass other
   input).

> If there's no clearly defined set, it's arbitrary.

There is a clearly defined set; see above for a definition.
 
> > > The Version 7  
> > > UNIX versions of these tools (circa 1979) described in the "CSTR 49"
> > > document you cite had several limitations (many related to having to
> > > run in 64k of code space on a pdp 11/70), that don't apply to modern
> > > troff implementations.
> > 
> > How is that relevant?  The CSTR documents have been updated.  
> 
> Some of the problems with ordering of preprocessors had to do with some
> preprocessors running out of memory if earlier preprocessors generated
> lots of output.

While that might be relevant to a recipient with a particular legacy
implementation, it is not relevant for the purpose of describing the
preprocessors, their order, their arguments, and environment settings
necessary for successful formatting of particular content.
 
> So design a parameter that specifies ordering without specifying the
> command-line.

See above reasons why that would be harmful to the intended use for
end-to-end, human-to-human communications intended for the parameter,
and why it would not deter determined but wayward implementers.
 
> The reality is that in practice troff isn't a single data format, it's 
> a lot of fairlly arbitrary variations on a format.

Not arbitrary.

> For this reason,  
> it doesn't lend itself to easy MIME typing.

As mentioned in the draft, some specific instances of content might be
more appropriately categorized under the image or application media
types.  The draft explicitly does not address those cases.

> So specifying a sane  
> MIME type for troff is a harder problem than it initially seems, 
> and you're running into that.

No, there's no particular difficulty in specifying the format for
text use.  Your complaints seem to boil down to implementers who
ignore existing recommendations which are reinforced in the draft
under discussion.  Nothing that can be said in this particular draft
is likely to change that for this media type or any other -- idiotic
implementers are what they are.  Making media types more difficult for
legitimate, conscientious users to use on the groundless assumption
that that will cause determined wayward implementers to see the light
smacks of a "nanny" or "Big Brother is Watching You" approach.

From: moore at cs.utk.edu (Keith Moore)
Date: Fri Apr 15 16:37:55 2005
Subject: regarding your comments on proposed media type text/troff' to Informational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> On Thu April 14 2005 22:49, Keith Moore wrote:
> > [cc'ed to ietf-types list, which per RFC 2048 is where this document
> > should be reviewed.]
> 
> Pre-draft discussions and earlier drafts have been discussed on
> ietf-types; 

And you dismissed the objections that other people raised about this
very issue on that list.

> > I raise this concern both because this was something that was
> > discussed  extensively in the ietf-822 working group that created
> > MIME, and also  because we've seen far too many security holes
> > result from giving the  sender a way to choose what program to run
> > on the recipient's system 
> 
> The "process" parameter is explicitly *NOT* "giving the sender a way
> to choose what program to run on the recipient's system".  It is a way
> for the sender to suggest a recommended processing sequence to the
> human recipient.  N.B. "suggest", "recommended", and "human".

It's a distinction without a practical difference.

> > RFC 2046 (section 4.5.1) even includes the following language, which
> > 
> > also appeared in RFCs 1341 and 1521:
> > 
> > >    To reduce the danger of transmitting rogue programs, it is
> > >    strongly recommended that implementations NOT implement a
> > >    path-search mechanism whereby an arbitrary program named in the
> > >    Content-Type parameter (e.g., an "interpreter=" parameter) is
> > >    found and executed using the message body as input.
> 
> I fully agree that implementations should take suitable precautions. I
> would (and have in the draft) go farther and state that
> implementations (w.r.t. text/troff) should not automatically process
> content other than possibly stripping directives for presentation. 
> And there are some specific additional recommendations for safe
> presentation whether or not directives are stripped (e.g. precautions
> against control characters). 

There have been similar recommendations in every version of the MIME
spec. Guess what?  They were consistently ignored by major vendors. 
Running code and hundreds of billions of dollars worth of damage due to
viruses  aptly demonstrates that even though the spec says "don't
present executable content" implementations will do it anyway.  The
process parameter is executable content.

> > and to allow the sender to  
> > specify arbitrary preprocessing programs and arbitrary parameters to
> > those programs.
> 
> The intent is to specify the preprocessors and parameters which will
> produce the output that the author intended, not arbitrary progams/
> parameters.  

If the author wants to enclose a Makefile or build script as a separate
text/plain attachment, he's free to do so.  

> The nature of the text media type is that subtypes of that type are
> (supposed to be) presentable to a user w/o processing of any type (as
> discussed in some detail in the draft).  As with some other "rich"
> text subtypes, the proposed text/troff may also be processed for
> improved presentation (e.g. to produce hard copy).  The "process"
> parameter merely provides hints for the recipient to perform such
> processing *IF* the recipient decides to do so.

It's a lousy way to do that.  Parameters are typically not displayed to
the recipient.  They're either interpreted my the MUA or ignored.

> > Nor am I persuaded by the "sender must specify the order of 
> > preprocessing" argument, as groff has options to specify which of 
> > several preprocessors to use, and it seems to work fine.
> 
> At the risk of being repetitive, no, groff's limited facility is
> inadequate:
> 
> o groff is not installed everywhere
> 
> o there are different versions of groff; some have no support for the
>   grap preprocessor
> 
> o no version of groff up to the present one has support for either
>   chem or dformat preprocessors, or for preprocessors such as the 
>   one for handling ABNF
> 
> o groff uses fixed order of preprocessing, with eqn last.  That fails
>   miserably for documents with equations in graphs (CSTR 114) or with
>   equations in tables (CSTR 49) or both
> 
> o groff's fixed order does not accommodate tables in diagrams, which
>   is certainly possible.

Let me get this straight.  First you argue that the process parameter
isn't intended to be executed, and then you argue that a different kind
of parameter that only specified the preprocessors to be used would 
not be appropriate because _it_ couldn't be executed?

And then you're arguing that the purpose of the process parameter
isn't to specify arbitrary code to be executed, but you also admit
that there's no clearly defined set of preprocessors for troff?
If there's no clearly defined set, it's arbitrary.

> > The Version 7  
> > UNIX versions of these tools (circa 1979) described in the "CSTR 49"
> > document you cite had several limitations (many related to having to
> > run in 64k of code space on a pdp 11/70), that don't apply to modern
> > troff implementations.
> 
> How is that relevant?  The CSTR documents have been updated.  

Some of the problems with ordering of preprocessors had to do with some
preprocessors running out of memory if earlier preprocessors generated
lots of output.

> Moreover,
> the primary consideration is the order which is necessary to produce
> proper formatted output; the order that works for tables in diagrams
> is different from the order that works for diagrams in tables, in a
> mutually exclusive relationship (i.e. there is no order that will
> cover both cases).

So design a parameter that specifies ordering without specifying the
command-line.

The reality is that in practice troff isn't a single data format, it's 
a lot of fairlly arbitrary variations on a format.  For this reason, 
it doesn't lend itself to easy MIME typing.  So specifying a sane 
MIME type for troff is a harder problem than it initially seems, 
and you're running into that.

Keith
>From [email-masked]  Fri Apr 15 16:36:54 2005
From: moore at cs.utk.edu (Keith Moore)
Date: Fri Apr 15 16:37:59 2005
Subject: regarding your comments on proposed media type text/troff' to
 Informational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

> On Thu April 14 2005 22:49, Keith Moore wrote:
> > [cc'ed to ietf-types list, which per RFC 2048 is where this document
> > should be reviewed.]
> 
> Pre-draft discussions and earlier drafts have been discussed on
> ietf-types; 

And you dismissed the objections that other people raised about this
very issue on that list.

> > I raise this concern both because this was something that was
> > discussed  extensively in the ietf-822 working group that created
> > MIME, and also  because we've seen far too many security holes
> > result from giving the  sender a way to choose what program to run
> > on the recipient's system 
> 
> The "process" parameter is explicitly *NOT* "giving the sender a way
> to choose what program to run on the recipient's system".  It is a way
> for the sender to suggest a recommended processing sequence to the
> human recipient.  N.B. "suggest", "recommended", and "human".

It's a distinction without a practical difference.

> > RFC 2046 (section 4.5.1) even includes the following language, which
> > 
> > also appeared in RFCs 1341 and 1521:
> > 
> > >    To reduce the danger of transmitting rogue programs, it is
> > >    strongly recommended that implementations NOT implement a
> > >    path-search mechanism whereby an arbitrary program named in the
> > >    Content-Type parameter (e.g., an "interpreter=" parameter) is
> > >    found and executed using the message body as input.
> 
> I fully agree that implementations should take suitable precautions. I
> would (and have in the draft) go farther and state that
> implementations (w.r.t. text/troff) should not automatically process
> content other than possibly stripping directives for presentation. 
> And there are some specific additional recommendations for safe
> presentation whether or not directives are stripped (e.g. precautions
> against control characters). 

There have been similar recommendations in every version of the MIME
spec. Guess what?  They were consistently ignored by major vendors. 
Running code and hundreds of billions of dollars worth of damage due to
viruses  aptly demonstrates that even though the spec says "don't
present executable content" implementations will do it anyway.  The
process parameter is executable content.

> > and to allow the sender to  
> > specify arbitrary preprocessing programs and arbitrary parameters to
> > those programs.
> 
> The intent is to specify the preprocessors and parameters which will
> produce the output that the author intended, not arbitrary progams/
> parameters.  

If the author wants to enclose a Makefile or build script as a separate
text/plain attachment, he's free to do so.  

> The nature of the text media type is that subtypes of that type are
> (supposed to be) presentable to a user w/o processing of any type (as
> discussed in some detail in the draft).  As with some other "rich"
> text subtypes, the proposed text/troff may also be processed for
> improved presentation (e.g. to produce hard copy).  The "process"
> parameter merely provides hints for the recipient to perform such
> processing *IF* the recipient decides to do so.

It's a lousy way to do that.  Parameters are typically not displayed to
the recipient.  They're either interpreted my the MUA or ignored.

> > Nor am I persuaded by the "sender must specify the order of 
> > preprocessing" argument, as groff has options to specify which of 
> > several preprocessors to use, and it seems to work fine.
> 
> At the risk of being repetitive, no, groff's limited facility is
> inadequate:
> 
> o groff is not installed everywhere
> 
> o there are different versions of groff; some have no support for the
>   grap preprocessor
> 
> o no version of groff up to the present one has support for either
>   chem or dformat preprocessors, or for preprocessors such as the 
>   one for handling ABNF
> 
> o groff uses fixed order of preprocessing, with eqn last.  That fails
>   miserably for documents with equations in graphs (CSTR 114) or with
>   equations in tables (CSTR 49) or both
> 
> o groff's fixed order does not accommodate tables in diagrams, which
>   is certainly possible.

Let me get this straight.  First you argue that the process parameter
isn't intended to be executed, and then you argue that a different kind
of parameter that only specified the preprocessors to be used would 
not be appropriate because _it_ couldn't be executed?

And then you're arguing that the purpose of the process parameter
isn't to specify arbitrary code to be executed, but you also admit
that there's no clearly defined set of preprocessors for troff?
If there's no clearly defined set, it's arbitrary.

> > The Version 7  
> > UNIX versions of these tools (circa 1979) described in the "CSTR 49"
> > document you cite had several limitations (many related to having to
> > run in 64k of code space on a pdp 11/70), that don't apply to modern
> > troff implementations.
> 
> How is that relevant?  The CSTR documents have been updated.  

Some of the problems with ordering of preprocessors had to do with some
preprocessors running out of memory if earlier preprocessors generated
lots of output.

> Moreover,
> the primary consideration is the order which is necessary to produce
> proper formatted output; the order that works for tables in diagrams
> is different from the order that works for diagrams in tables, in a
> mutually exclusive relationship (i.e. there is no order that will
> cover both cases).

So design a parameter that specifies ordering without specifying the
command-line.

The reality is that in practice troff isn't a single data format, it's 
a lot of fairlly arbitrary variations on a format.  For this reason, 
it doesn't lend itself to easy MIME typing.  So specifying a sane 
MIME type for troff is a harder problem than it initially seems, 
and you're running into that.

Keith
>From [email-masked]  Sat Apr 16 17:12:35 2005
From: blilly at erols.com (Bruce Lilly)
Date: Sat Apr 16 17:12:52 2005
Subject: regarding your comments on proposed media type text/troff' to
	Informational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Fri April 15 2005 10:36, Keith Moore wrote:

> And you dismissed the objections that other people raised about this
> very issue on that list.

No, wording of the draft was changed as a result.

> > The "process" parameter is explicitly *NOT* "giving the sender a way
> > to choose what program to run on the recipient's system".  It is a way
> > for the sender to suggest a recommended processing sequence to the
> > human recipient.  N.B. "suggest", "recommended", and "human".
> 
> It's a distinction without a practical difference.

No, if some wayward implementer were to automatically execute programs
contrary to the specification, said implementer can be informed that he
is out of line.  That is a very real "practical difference" between the
actual draft and your mischaracterization of what the draft says.  You
seem to:
a) want to remove any standardized mechanism for the author to convey
   relevant information to the recipient
b) believe that groff can magically determine preprocessors, an
   appropriate ordering of preprocessors with appropriate arguments,
   etc.
Removal of the "process" parameter will not prevent a wayward implementer
from simply automatically invoking groff; removal of the parameter
therefore will not address inappropriate use of the media type and
metadata, and removal of discussion of inappropriate use of said parameter
along with its specification would leave no stick with which to educate
such implementers.  It will, however, impair legitimate uses of the media
type and metadata.

> There have been similar recommendations in every version of the MIME
> spec. Guess what?  They were consistently ignored by major vendors. 
> Running code and hundreds of billions of dollars worth of damage due to
> viruses  aptly demonstrates that even though the spec says "don't
> present executable content" implementations will do it anyway.

Don't blame me for inappropriate behavior of some unrelated vendor. If
multiple recommendations haven't prevented inappropriate implementations,
what leads you to the conclusion that failing to make recommendations
will improve matters?

> The 
> process parameter is executable content.

No, it's a human-writable, human-readable hint in a well-understood,
precise, concise, standardized (e.g. POSIX) format.
 
> > The intent is to specify the preprocessors and parameters which will
> > produce the output that the author intended, not arbitrary progams/
> > parameters.  
> 
> If the author wants to enclose a Makefile or build script as a separate
> text/plain attachment, he's free to do so.  

You seem to be fixated on a niche application of media types, which are
being separated from the mail environment.  In general, there is nothing
in which to "enclose" separate content, or to which to make an
"attachment".  Consider, as an example of possible use outside of a mail
environment, a means of recording such metadata in some sort of database
with entries for files (e.g. similar to a MacOS "resource fork", or the
comments field which can be set for files in recent versions of MS
Windows).

Moreover, a "build script" would fit into the category of "languages for
'active' (computational) material", which is the application media type,
not text, and certainly not text/plain.  See
draft-freed-media-type-reg-04.txt.
 
> It's a lousy way to do that.  Parameters are typically not displayed to
> the recipient.  They're either interpreted my the MUA or ignored.

Again, you're fixated on a mail environment, which is not the only
application for media types.
 
> Let me get this straight.

OK, I'll try to clarify the situation.

> First you argue that the process parameter 
> isn't intended to be executed,

Not intended to be automatically executed.  If the human recipient,
after exercising due caution, wishes to follow the suggestion supplied
by the content author, he is of course free to do so -- or he can
execute some other, possibly similar set of processes, or he can choose
not to format the content.

> and then you argue that a different kind 
> of parameter that only specified the preprocessors to be used would 
> not be appropriate because _it_ couldn't be executed?

No, the objections to a mere unordered list of preprocessors includes:

1. preprocessor order is critically important
2. preprocessor arguments are critically important
3. environment variables (e.g. GROFF_NO_SGR in recent groff versions)
   may be critically important
4. formatter arguments are critically important
5. postprocessing may be required

Your suggestion addresses none of those issues, all of which are
accommodated by command-line syntax.  Moreover:

I. command-line syntax is easy for an author to indicate, with precision
   and conciseness
II. command-line syntax can be read, understood, modified if desired,
   and used by recipients.

A mere list lacks those characteristics.  Obfuscating processing steps
by some sort of mechanical translation of easily-generated, easily-read
syntax adds extra manual, error-prone steps for both author and recipient,
but will not slow down a wayward implementer who is determined to
automatically pass content to a program; he'll simply automate the
translation.  That would have precisely the opposite effect of the
current wording of the draft; it would make legitimate use difficult
while making automated misuse straightforward.

> And then you're arguing that the purpose of the process parameter
> isn't to specify arbitrary code to be executed,

Correct.

> but you also admit 
> that there's no clearly defined set of preprocessors for troff?

No, at any given time, one can enumerate a set of preprocessors, as has
been done in the registration template in the draft under discussion --
but that set may change over time as new preprocessors are developed.
One can clearly define a set of preprocessors as programs with the
following characteristics:

i. the program operates as a filter, accepting input and producing
   output (as opposed to programs which do not do both, such as "ls",
   etc.)
ii. The input and output formats conform to troff format conventions as
   specified in CSTR 54, e.g. directives intermixed with text, directives
   begin with dot, etc.
iii. input is human-readable content describing some abstract format
   which is translated into formatting directives or to another human-
   readable format for further processing with the ultimate goal being
   production of formatted output
iv. the input to be preprocessed is delimited by specified directives,
   and other input is passed to the output unaltered (so the programs
   in the graphviz suite, which can generate pic output, do not
   qualify as preprocessors because they do not accept/pass other
   input).

> If there's no clearly defined set, it's arbitrary.

There is a clearly defined set; see above for a definition.
 
> > > The Version 7  
> > > UNIX versions of these tools (circa 1979) described in the "CSTR 49"
> > > document you cite had several limitations (many related to having to
> > > run in 64k of code space on a pdp 11/70), that don't apply to modern
> > > troff implementations.
> > 
> > How is that relevant?  The CSTR documents have been updated.  
> 
> Some of the problems with ordering of preprocessors had to do with some
> preprocessors running out of memory if earlier preprocessors generated
> lots of output.

While that might be relevant to a recipient with a particular legacy
implementation, it is not relevant for the purpose of describing the
preprocessors, their order, their arguments, and environment settings
necessary for successful formatting of particular content.
 
> So design a parameter that specifies ordering without specifying the
> command-line.

See above reasons why that would be harmful to the intended use for
end-to-end, human-to-human communications intended for the parameter,
and why it would not deter determined but wayward implementers.
 
> The reality is that in practice troff isn't a single data format, it's 
> a lot of fairlly arbitrary variations on a format.

Not arbitrary.

> For this reason,  
> it doesn't lend itself to easy MIME typing.

As mentioned in the draft, some specific instances of content might be
more appropriately categorized under the image or application media
types.  The draft explicitly does not address those cases.

> So specifying a sane  
> MIME type for troff is a harder problem than it initially seems, 
> and you're running into that.

No, there's no particular difficulty in specifying the format for
text use.  Your complaints seem to boil down to implementers who
ignore existing recommendations which are reinforced in the draft
under discussion.  Nothing that can be said in this particular draft
is likely to change that for this media type or any other -- idiotic
implementers are what they are.  Making media types more difficult for
legitimate, conscientious users to use on the groundless assumption
that that will cause determined wayward implementers to see the light
smacks of a "nanny" or "Big Brother is Watching You" approach.
>From [email-masked]  Sat Apr 16 17:12:35 2005
From: blilly at erols.com (Bruce Lilly)
Date: Sat Apr 16 17:12:54 2005
Subject: regarding your comments on proposed media type text/troff' to
	Informational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Fri April 15 2005 10:36, Keith Moore wrote:

> And you dismissed the objections that other people raised about this
> very issue on that list.

No, wording of the draft was changed as a result.

> > The "process" parameter is explicitly *NOT* "giving the sender a way
> > to choose what program to run on the recipient's system".  It is a way
> > for the sender to suggest a recommended processing sequence to the
> > human recipient.  N.B. "suggest", "recommended", and "human".
> 
> It's a distinction without a practical difference.

No, if some wayward implementer were to automatically execute programs
contrary to the specification, said implementer can be informed that he
is out of line.  That is a very real "practical difference" between the
actual draft and your mischaracterization of what the draft says.  You
seem to:
a) want to remove any standardized mechanism for the author to convey
   relevant information to the recipient
b) believe that groff can magically determine preprocessors, an
   appropriate ordering of preprocessors with appropriate arguments,
   etc.
Removal of the "process" parameter will not prevent a wayward implementer
from simply automatically invoking groff; removal of the parameter
therefore will not address inappropriate use of the media type and
metadata, and removal of discussion of inappropriate use of said parameter
along with its specification would leave no stick with which to educate
such implementers.  It will, however, impair legitimate uses of the media
type and metadata.

> There have been similar recommendations in every version of the MIME
> spec. Guess what?  They were consistently ignored by major vendors. 
> Running code and hundreds of billions of dollars worth of damage due to
> viruses  aptly demonstrates that even though the spec says "don't
> present executable content" implementations will do it anyway.

Don't blame me for inappropriate behavior of some unrelated vendor. If
multiple recommendations haven't prevented inappropriate implementations,
what leads you to the conclusion that failing to make recommendations
will improve matters?

> The 
> process parameter is executable content.

No, it's a human-writable, human-readable hint in a well-understood,
precise, concise, standardized (e.g. POSIX) format.
 
> > The intent is to specify the preprocessors and parameters which will
> > produce the output that the author intended, not arbitrary progams/
> > parameters.  
> 
> If the author wants to enclose a Makefile or build script as a separate
> text/plain attachment, he's free to do so.  

You seem to be fixated on a niche application of media types, which are
being separated from the mail environment.  In general, there is nothing
in which to "enclose" separate content, or to which to make an
"attachment".  Consider, as an example of possible use outside of a mail
environment, a means of recording such metadata in some sort of database
with entries for files (e.g. similar to a MacOS "resource fork", or the
comments field which can be set for files in recent versions of MS
Windows).

Moreover, a "build script" would fit into the category of "languages for
'active' (computational) material", which is the application media type,
not text, and certainly not text/plain.  See
draft-freed-media-type-reg-04.txt.
 
> It's a lousy way to do that.  Parameters are typically not displayed to
> the recipient.  They're either interpreted my the MUA or ignored.

Again, you're fixated on a mail environment, which is not the only
application for media types.
 
> Let me get this straight.

OK, I'll try to clarify the situation.

> First you argue that the process parameter 
> isn't intended to be executed,

Not intended to be automatically executed.  If the human recipient,
after exercising due caution, wishes to follow the suggestion supplied
by the content author, he is of course free to do so -- or he can
execute some other, possibly similar set of processes, or he can choose
not to format the content.

> and then you argue that a different kind 
> of parameter that only specified the preprocessors to be used would 
> not be appropriate because _it_ couldn't be executed?

No, the objections to a mere unordered list of preprocessors includes:

1. preprocessor order is critically important
2. preprocessor arguments are critically important
3. environment variables (e.g. GROFF_NO_SGR in recent groff versions)
   may be critically important
4. formatter arguments are critically important
5. postprocessing may be required

Your suggestion addresses none of those issues, all of which are
accommodated by command-line syntax.  Moreover:

I. command-line syntax is easy for an author to indicate, with precision
   and conciseness
II. command-line syntax can be read, understood, modified if desired,
   and used by recipients.

A mere list lacks those characteristics.  Obfuscating processing steps
by some sort of mechanical translation of easily-generated, easily-read
syntax adds extra manual, error-prone steps for both author and recipient,
but will not slow down a wayward implementer who is determined to
automatically pass content to a program; he'll simply automate the
translation.  That would have precisely the opposite effect of the
current wording of the draft; it would make legitimate use difficult
while making automated misuse straightforward.

> And then you're arguing that the purpose of the process parameter
> isn't to specify arbitrary code to be executed,

Correct.

> but you also admit 
> that there's no clearly defined set of preprocessors for troff?

No, at any given time, one can enumerate a set of preprocessors, as has
been done in the registration template in the draft under discussion --
but that set may change over time as new preprocessors are developed.
One can clearly define a set of preprocessors as programs with the
following characteristics:

i. the program operates as a filter, accepting input and producing
   output (as opposed to programs which do not do both, such as "ls",
   etc.)
ii. The input and output formats conform to troff format conventions as
   specified in CSTR 54, e.g. directives intermixed with text, directives
   begin with dot, etc.
iii. input is human-readable content describing some abstract format
   which is translated into formatting directives or to another human-
   readable format for further processing with the ultimate goal being
   production of formatted output
iv. the input to be preprocessed is delimited by specified directives,
   and other input is passed to the output unaltered (so the programs
   in the graphviz suite, which can generate pic output, do not
   qualify as preprocessors because they do not accept/pass other
   input).

> If there's no clearly defined set, it's arbitrary.

There is a clearly defined set; see above for a definition.
 
> > > The Version 7  
> > > UNIX versions of these tools (circa 1979) described in the "CSTR 49"
> > > document you cite had several limitations (many related to having to
> > > run in 64k of code space on a pdp 11/70), that don't apply to modern
> > > troff implementations.
> > 
> > How is that relevant?  The CSTR documents have been updated.  
> 
> Some of the problems with ordering of preprocessors had to do with some
> preprocessors running out of memory if earlier preprocessors generated
> lots of output.

While that might be relevant to a recipient with a particular legacy
implementation, it is not relevant for the purpose of describing the
preprocessors, their order, their arguments, and environment settings
necessary for successful formatting of particular content.
 
> So design a parameter that specifies ordering without specifying the
> command-line.

See above reasons why that would be harmful to the intended use for
end-to-end, human-to-human communications intended for the parameter,
and why it would not deter determined but wayward implementers.
 
> The reality is that in practice troff isn't a single data format, it's 
> a lot of fairlly arbitrary variations on a format.

Not arbitrary.

> For this reason,  
> it doesn't lend itself to easy MIME typing.

As mentioned in the draft, some specific instances of content might be
more appropriately categorized under the image or application media
types.  The draft explicitly does not address those cases.

> So specifying a sane  
> MIME type for troff is a harder problem than it initially seems, 
> and you're running into that.

No, there's no particular difficulty in specifying the format for
text use.  Your complaints seem to boil down to implementers who
ignore existing recommendations which are reinforced in the draft
under discussion.  Nothing that can be said in this particular draft
is likely to change that for this media type or any other -- idiotic
implementers are what they are.  Making media types more difficult for
legitimate, conscientious users to use on the groundless assumption
that that will cause determined wayward implementers to see the light
smacks of a "nanny" or "Big Brother is Watching You" approach.
>From [email-masked]  Sun Apr 17 00:46:16 2005
From: moore at cs.utk.edu (Keith Moore)
Date: Sun Apr 17 00:46:45 2005
Subject: regarding your comments on proposed media type text/troff' to
	Informational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Bruce,

bottom line - this parameter violates both the intent and the wording 
of the MIME spec.  it's simply unacceptable.
solve the problem in a different way.

Keith

On Apr 16, 2005, at 11:12 AM, Bruce Lilly wrote:

> On Fri April 15 2005 10:36, Keith Moore wrote:
>
>> And you dismissed the objections that other people raised about this
>> very issue on that list.
>
> No, wording of the draft was changed as a result.
>
>>> The "process" parameter is explicitly *NOT* "giving the sender a way
>>> to choose what program to run on the recipient's system".  It is a 
>>> way
>>> for the sender to suggest a recommended processing sequence to the
>>> human recipient.  N.B. "suggest", "recommended", and "human".
>>
>> It's a distinction without a practical difference.
>
> No, if some wayward implementer were to automatically execute programs
> contrary to the specification, said implementer can be informed that he
> is out of line.  That is a very real "practical difference" between the
> actual draft and your mischaracterization of what the draft says.  You
> seem to:
> a) want to remove any standardized mechanism for the author to convey
>    relevant information to the recipient
> b) believe that groff can magically determine preprocessors, an
>    appropriate ordering of preprocessors with appropriate arguments,
>    etc.
> Removal of the "process" parameter will not prevent a wayward 
> implementer
> from simply automatically invoking groff; removal of the parameter
> therefore will not address inappropriate use of the media type and
> metadata, and removal of discussion of inappropriate use of said 
> parameter
> along with its specification would leave no stick with which to educate
> such implementers.  It will, however, impair legitimate uses of the 
> media
> type and metadata.
>
>> There have been similar recommendations in every version of the MIME
>> spec. Guess what?  They were consistently ignored by major vendors.
>> Running code and hundreds of billions of dollars worth of damage due 
>> to
>> viruses  aptly demonstrates that even though the spec says "don't
>> present executable content" implementations will do it anyway.
>
> Don't blame me for inappropriate behavior of some unrelated vendor. If
> multiple recommendations haven't prevented inappropriate 
> implementations,
> what leads you to the conclusion that failing to make recommendations
> will improve matters?
>
>> The
>> process parameter is executable content.
>
> No, it's a human-writable, human-readable hint in a well-understood,
> precise, concise, standardized (e.g. POSIX) format.
>
>>> The intent is to specify the preprocessors and parameters which will
>>> produce the output that the author intended, not arbitrary progams/
>>> parameters.
>>
>> If the author wants to enclose a Makefile or build script as a 
>> separate
>> text/plain attachment, he's free to do so.
>
> You seem to be fixated on a niche application of media types, which are
> being separated from the mail environment.  In general, there is 
> nothing
> in which to "enclose" separate content, or to which to make an
> "attachment".  Consider, as an example of possible use outside of a 
> mail
> environment, a means of recording such metadata in some sort of 
> database
> with entries for files (e.g. similar to a MacOS "resource fork", or the
> comments field which can be set for files in recent versions of MS
> Windows).
>
> Moreover, a "build script" would fit into the category of "languages 
> for
> 'active' (computational) material", which is the application media 
> type,
> not text, and certainly not text/plain.  See
> draft-freed-media-type-reg-04.txt.
>
>> It's a lousy way to do that.  Parameters are typically not displayed 
>> to
>> the recipient.  They're either interpreted my the MUA or ignored.
>
> Again, you're fixated on a mail environment, which is not the only
> application for media types.
>
>> Let me get this straight.
>
> OK, I'll try to clarify the situation.
>
>> First you argue that the process parameter
>> isn't intended to be executed,
>
> Not intended to be automatically executed.  If the human recipient,
> after exercising due caution, wishes to follow the suggestion supplied
> by the content author, he is of course free to do so -- or he can
> execute some other, possibly similar set of processes, or he can choose
> not to format the content.
>
>> and then you argue that a different kind
>> of parameter that only specified the preprocessors to be used would
>> not be appropriate because _it_ couldn't be executed?
>
> No, the objections to a mere unordered list of preprocessors includes:
>
> 1. preprocessor order is critically important
> 2. preprocessor arguments are critically important
> 3. environment variables (e.g. GROFF_NO_SGR in recent groff versions)
>    may be critically important
> 4. formatter arguments are critically important
> 5. postprocessing may be required
>
> Your suggestion addresses none of those issues, all of which are
> accommodated by command-line syntax.  Moreover:
>
> I. command-line syntax is easy for an author to indicate, with 
> precision
>    and conciseness
> II. command-line syntax can be read, understood, modified if desired,
>    and used by recipients.
>
> A mere list lacks those characteristics.  Obfuscating processing steps
> by some sort of mechanical translation of easily-generated, easily-read
> syntax adds extra manual, error-prone steps for both author and 
> recipient,
> but will not slow down a wayward implementer who is determined to
> automatically pass content to a program; he'll simply automate the
> translation.  That would have precisely the opposite effect of the
> current wording of the draft; it would make legitimate use difficult
> while making automated misuse straightforward.
>
>> And then you're arguing that the purpose of the process parameter
>> isn't to specify arbitrary code to be executed,
>
> Correct.
>
>> but you also admit
>> that there's no clearly defined set of preprocessors for troff?
>
> No, at any given time, one can enumerate a set of preprocessors, as has
> been done in the registration template in the draft under discussion --
> but that set may change over time as new preprocessors are developed.
> One can clearly define a set of preprocessors as programs with the
> following characteristics:
>
> i. the program operates as a filter, accepting input and producing
>    output (as opposed to programs which do not do both, such as "ls",
>    etc.)
> ii. The input and output formats conform to troff format conventions as
>    specified in CSTR 54, e.g. directives intermixed with text, 
> directives
>    begin with dot, etc.
> iii. input is human-readable content describing some abstract format
>    which is translated into formatting directives or to another human-
>    readable format for further processing with the ultimate goal being
>    production of formatted output
> iv. the input to be preprocessed is delimited by specified directives,
>    and other input is passed to the output unaltered (so the programs
>    in the graphviz suite, which can generate pic output, do not
>    qualify as preprocessors because they do not accept/pass other
>    input).
>
>> If there's no clearly defined set, it's arbitrary.
>
> There is a clearly defined set; see above for a definition.
>
>>>> The Version 7
>>>> UNIX versions of these tools (circa 1979) described in the "CSTR 49"
>>>> document you cite had several limitations (many related to having to
>>>> run in 64k of code space on a pdp 11/70), that don't apply to modern
>>>> troff implementations.
>>>
>>> How is that relevant?  The CSTR documents have been updated.
>>
>> Some of the problems with ordering of preprocessors had to do with 
>> some
>> preprocessors running out of memory if earlier preprocessors generated
>> lots of output.
>
> While that might be relevant to a recipient with a particular legacy
> implementation, it is not relevant for the purpose of describing the
> preprocessors, their order, their arguments, and environment settings
> necessary for successful formatting of particular content.
>
>> So design a parameter that specifies ordering without specifying the
>> command-line.
>
> See above reasons why that would be harmful to the intended use for
> end-to-end, human-to-human communications intended for the parameter,
> and why it would not deter determined but wayward implementers.
>
>> The reality is that in practice troff isn't a single data format, it's
>> a lot of fairlly arbitrary variations on a format.
>
> Not arbitrary.
>
>> For this reason,
>> it doesn't lend itself to easy MIME typing.
>
> As mentioned in the draft, some specific instances of content might be
> more appropriately categorized under the image or application media
> types.  The draft explicitly does not address those cases.
>
>> So specifying a sane
>> MIME type for troff is a harder problem than it initially seems,
>> and you're running into that.
>
> No, there's no particular difficulty in specifying the format for
> text use.  Your complaints seem to boil down to implementers who
> ignore existing recommendations which are reinforced in the draft
> under discussion.  Nothing that can be said in this particular draft
> is likely to change that for this media type or any other -- idiotic
> implementers are what they are.  Making media types more difficult for
> legitimate, conscientious users to use on the groundless assumption
> that that will cause determined wayward implementers to see the light
> smacks of a "nanny" or "Big Brother is Watching You" approach.

From: moore at cs.utk.edu (Keith Moore)
Date: Tue Jan  3 16:22:58 2006
Subject: regarding your comments on proposed media type text/troff' to Informational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> On Thu April 14 2005 22:49, Keith Moore wrote:
> > [cc'ed to ietf-types list, which per RFC 2048 is where this document
> > should be reviewed.]
> 
> Pre-draft discussions and earlier drafts have been discussed on
> ietf-types; 

And you dismissed the objections that other people raised about this
very issue on that list.

> > I raise this concern both because this was something that was
> > discussed  extensively in the ietf-822 working group that created
> > MIME, and also  because we've seen far too many security holes
> > result from giving the  sender a way to choose what program to run
> > on the recipient's system 
> 
> The "process" parameter is explicitly *NOT* "giving the sender a way
> to choose what program to run on the recipient's system".  It is a way
> for the sender to suggest a recommended processing sequence to the
> human recipient.  N.B. "suggest", "recommended", and "human".

It's a distinction without a practical difference.

> > RFC 2046 (section 4.5.1) even includes the following language, which
> > 
> > also appeared in RFCs 1341 and 1521:
> > 
> > >    To reduce the danger of transmitting rogue programs, it is
> > >    strongly recommended that implementations NOT implement a
> > >    path-search mechanism whereby an arbitrary program named in the
> > >    Content-Type parameter (e.g., an "interpreter=" parameter) is
> > >    found and executed using the message body as input.
> 
> I fully agree that implementations should take suitable precautions. I
> would (and have in the draft) go farther and state that
> implementations (w.r.t. text/troff) should not automatically process
> content other than possibly stripping directives for presentation. 
> And there are some specific additional recommendations for safe
> presentation whether or not directives are stripped (e.g. precautions
> against control characters). 

There have been similar recommendations in every version of the MIME
spec. Guess what?  They were consistently ignored by major vendors. 
Running code and hundreds of billions of dollars worth of damage due to
viruses  aptly demonstrates that even though the spec says "don't
present executable content" implementations will do it anyway.  The
process parameter is executable content.

> > and to allow the sender to  
> > specify arbitrary preprocessing programs and arbitrary parameters to
> > those programs.
> 
> The intent is to specify the preprocessors and parameters which will
> produce the output that the author intended, not arbitrary progams/
> parameters.  

If the author wants to enclose a Makefile or build script as a separate
text/plain attachment, he's free to do so.  

> The nature of the text media type is that subtypes of that type are
> (supposed to be) presentable to a user w/o processing of any type (as
> discussed in some detail in the draft).  As with some other "rich"
> text subtypes, the proposed text/troff may also be processed for
> improved presentation (e.g. to produce hard copy).  The "process"
> parameter merely provides hints for the recipient to perform such
> processing *IF* the recipient decides to do so.

It's a lousy way to do that.  Parameters are typically not displayed to
the recipient.  They're either interpreted my the MUA or ignored.

> > Nor am I persuaded by the "sender must specify the order of 
> > preprocessing" argument, as groff has options to specify which of 
> > several preprocessors to use, and it seems to work fine.
> 
> At the risk of being repetitive, no, groff's limited facility is
> inadequate:
> 
> o groff is not installed everywhere
> 
> o there are different versions of groff; some have no support for the
>   grap preprocessor
> 
> o no version of groff up to the present one has support for either
>   chem or dformat preprocessors, or for preprocessors such as the 
>   one for handling ABNF
> 
> o groff uses fixed order of preprocessing, with eqn last.  That fails
>   miserably for documents with equations in graphs (CSTR 114) or with
>   equations in tables (CSTR 49) or both
> 
> o groff's fixed order does not accommodate tables in diagrams, which
>   is certainly possible.

Let me get this straight.  First you argue that the process parameter
isn't intended to be executed, and then you argue that a different kind
of parameter that only specified the preprocessors to be used would 
not be appropriate because _it_ couldn't be executed?

And then you're arguing that the purpose of the process parameter
isn't to specify arbitrary code to be executed, but you also admit
that there's no clearly defined set of preprocessors for troff?
If there's no clearly defined set, it's arbitrary.

> > The Version 7  
> > UNIX versions of these tools (circa 1979) described in the "CSTR 49"
> > document you cite had several limitations (many related to having to
> > run in 64k of code space on a pdp 11/70), that don't apply to modern
> > troff implementations.
> 
> How is that relevant?  The CSTR documents have been updated.  

Some of the problems with ordering of preprocessors had to do with some
preprocessors running out of memory if earlier preprocessors generated
lots of output.

> Moreover,
> the primary consideration is the order which is necessary to produce
> proper formatted output; the order that works for tables in diagrams
> is different from the order that works for diagrams in tables, in a
> mutually exclusive relationship (i.e. there is no order that will
> cover both cases).

So design a parameter that specifies ordering without specifying the
command-line.

The reality is that in practice troff isn't a single data format, it's 
a lot of fairlly arbitrary variations on a format.  For this reason, 
it doesn't lend itself to easy MIME typing.  So specifying a sane 
MIME type for troff is a harder problem than it initially seems, 
and you're running into that.

Keith

From: moore at cs.utk.edu (Keith Moore)
Date: Tue Jan  3 16:22:58 2006
Subject: regarding your comments on proposed media type text/troff' to Informational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> On Thu April 14 2005 22:49, Keith Moore wrote:
> > [cc'ed to ietf-types list, which per RFC 2048 is where this document
> > should be reviewed.]
> 
> Pre-draft discussions and earlier drafts have been discussed on
> ietf-types; 

And you dismissed the objections that other people raised about this
very issue on that list.

> > I raise this concern both because this was something that was
> > discussed  extensively in the ietf-822 working group that created
> > MIME, and also  because we've seen far too many security holes
> > result from giving the  sender a way to choose what program to run
> > on the recipient's system 
> 
> The "process" parameter is explicitly *NOT* "giving the sender a way
> to choose what program to run on the recipient's system".  It is a way
> for the sender to suggest a recommended processing sequence to the
> human recipient.  N.B. "suggest", "recommended", and "human".

It's a distinction without a practical difference.

> > RFC 2046 (section 4.5.1) even includes the following language, which
> > 
> > also appeared in RFCs 1341 and 1521:
> > 
> > >    To reduce the danger of transmitting rogue programs, it is
> > >    strongly recommended that implementations NOT implement a
> > >    path-search mechanism whereby an arbitrary program named in the
> > >    Content-Type parameter (e.g., an "interpreter=" parameter) is
> > >    found and executed using the message body as input.
> 
> I fully agree that implementations should take suitable precautions. I
> would (and have in the draft) go farther and state that
> implementations (w.r.t. text/troff) should not automatically process
> content other than possibly stripping directives for presentation. 
> And there are some specific additional recommendations for safe
> presentation whether or not directives are stripped (e.g. precautions
> against control characters). 

There have been similar recommendations in every version of the MIME
spec. Guess what?  They were consistently ignored by major vendors. 
Running code and hundreds of billions of dollars worth of damage due to
viruses  aptly demonstrates that even though the spec says "don't
present executable content" implementations will do it anyway.  The
process parameter is executable content.

> > and to allow the sender to  
> > specify arbitrary preprocessing programs and arbitrary parameters to
> > those programs.
> 
> The intent is to specify the preprocessors and parameters which will
> produce the output that the author intended, not arbitrary progams/
> parameters.  

If the author wants to enclose a Makefile or build script as a separate
text/plain attachment, he's free to do so.  

> The nature of the text media type is that subtypes of that type are
> (supposed to be) presentable to a user w/o processing of any type (as
> discussed in some detail in the draft).  As with some other "rich"
> text subtypes, the proposed text/troff may also be processed for
> improved presentation (e.g. to produce hard copy).  The "process"
> parameter merely provides hints for the recipient to perform such
> processing *IF* the recipient decides to do so.

It's a lousy way to do that.  Parameters are typically not displayed to
the recipient.  They're either interpreted my the MUA or ignored.

> > Nor am I persuaded by the "sender must specify the order of 
> > preprocessing" argument, as groff has options to specify which of 
> > several preprocessors to use, and it seems to work fine.
> 
> At the risk of being repetitive, no, groff's limited facility is
> inadequate:
> 
> o groff is not installed everywhere
> 
> o there are different versions of groff; some have no support for the
>   grap preprocessor
> 
> o no version of groff up to the present one has support for either
>   chem or dformat preprocessors, or for preprocessors such as the 
>   one for handling ABNF
> 
> o groff uses fixed order of preprocessing, with eqn last.  That fails
>   miserably for documents with equations in graphs (CSTR 114) or with
>   equations in tables (CSTR 49) or both
> 
> o groff's fixed order does not accommodate tables in diagrams, which
>   is certainly possible.

Let me get this straight.  First you argue that the process parameter
isn't intended to be executed, and then you argue that a different kind
of parameter that only specified the preprocessors to be used would 
not be appropriate because _it_ couldn't be executed?

And then you're arguing that the purpose of the process parameter
isn't to specify arbitrary code to be executed, but you also admit
that there's no clearly defined set of preprocessors for troff?
If there's no clearly defined set, it's arbitrary.

> > The Version 7  
> > UNIX versions of these tools (circa 1979) described in the "CSTR 49"
> > document you cite had several limitations (many related to having to
> > run in 64k of code space on a pdp 11/70), that don't apply to modern
> > troff implementations.
> 
> How is that relevant?  The CSTR documents have been updated.  

Some of the problems with ordering of preprocessors had to do with some
preprocessors running out of memory if earlier preprocessors generated
lots of output.

> Moreover,
> the primary consideration is the order which is necessary to produce
> proper formatted output; the order that works for tables in diagrams
> is different from the order that works for diagrams in tables, in a
> mutually exclusive relationship (i.e. there is no order that will
> cover both cases).

So design a parameter that specifies ordering without specifying the
command-line.

The reality is that in practice troff isn't a single data format, it's 
a lot of fairlly arbitrary variations on a format.  For this reason, 
it doesn't lend itself to easy MIME typing.  So specifying a sane 
MIME type for troff is a harder problem than it initially seems, 
and you're running into that.

Keith

From: blilly at erols.com (Bruce Lilly)
Date: Fri Apr 15 15:46:04 2005
Subject: regarding your comments on proposed media type text/troff' to Informational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Thu April 14 2005 22:49, Keith Moore wrote:
> [cc'ed to ietf-types list, which per RFC 2048 is where this document 
> should be reviewed.]

Pre-draft discussions and earlier drafts have been discussed on
ietf-types; as the current draft is in Last Call, I've restored
copies to the IESG list.

> Bruce,
> 
> I raise this concern both because this was something that was discussed 
> extensively in the ietf-822 working group that created MIME, and also 
> because we've seen far too many security holes result from giving the 
> sender a way to choose what program to run on the recipient's system 

The "process" parameter is explicitly *NOT* "giving the sender a way to
choose what program to run on the recipient's system".  It is a way for
the sender to suggest a recommended processing sequence to the human
recipient.  N.B. "suggest", "recommended", and "human".

> (usually by ignoring the content-type parameter and paying attention to 
> the application-specific filename suffix).

There is a detailed discussion of suffixes (a.k.a. "extensions") in the
draft.

> Even if we don't think  
> troff will be used much, it sets a bad precedent to allow a new 
> content-type to specify something that we have ample experience to 
> indicate it's harmful.
> 
> RFC 2046 (section 4.5.1) even includes the following language, which 
> also appeared in RFCs 1341 and 1521:
> 
> >    To reduce the danger of transmitting rogue programs, it is strongly
> >    recommended that implementations NOT implement a path-search
> >    mechanism whereby an arbitrary program named in the Content-Type
> >    parameter (e.g., an "interpreter=" parameter) is found and executed
> >    using the message body as input.

I fully agree that implementations should take suitable precautions. I
would (and have in the draft) go farther and state that implementations
(w.r.t. text/troff) should not automatically process content other than
possibly stripping directives for presentation.  And there are some
specific additional recommendations for safe presentation whether or
not directives are stripped (e.g. precautions against control
characters). 

> now this is in a section related to the application/octet-stream 
> content-type, but the principle is the same - if you let the sender 
> choose what programs should be used to process the input, the 
> content-type label is effectively ignored.

Again, that's not what is being done.

> And the only difference  
> between an "interpreter" parameter and a "process" parameter is that 
> you're not only letting the sender specify the interpreter, you're 
> letting him specify the entire command line!

Either way, we're agreed that *implementations* should not automatically
execute such programs.

> I don't think it matters much if you say "don't directly execute the 
> process parameter" because the very purpose of the process parameter is 
> to tell the sender exactly what to type,

ITYM "recipient".  And it's a suggestion, not an imperative.

> and to allow the sender to  
> specify arbitrary preprocessing programs and arbitrary parameters to 
> those programs.

The intent is to specify the preprocessors and parameters which will
produce the output that the author intended, not arbitrary progams/
parameters.  Certainly the mechanism could be abused, just as sending
a plain text message ("social engineering") can be abused.

> Maybe recipients should know better than type  
> arbitrary commands specified by the sender, but there's ample 
> experience to suggest that most recipients don't have that kind of 
> expertise.

The nature of the text media type is that subtypes of that type are
(supposed to be) presentable to a user w/o processing of any type (as
discussed in some detail in the draft).  As with some other "rich" text
subtypes, the proposed text/troff may also be processed for improved
presentation (e.g. to produce hard copy).  The "process" parameter
merely provides hints for the recipient to perform such processing
*IF* the recipient decides to do so.

> Nor am I persuaded by the "sender must specify the order of 
> preprocessing" argument, as groff has options to specify which of 
> several preprocessors to use, and it seems to work fine.

At the risk of being repetitive, no, groff's limited facility is
inadequate:

o groff is not installed everywhere

o there are different versions of groff; some have no support for the
  grap preprocessor

o no version of groff up to the present one has support for either chem
  or dformat preprocessors, or for preprocessors such as the one for
  handling ABNF

o groff uses fixed order of preprocessing, with eqn last.  That fails
  miserably for documents with equations in graphs (CSTR 114) or with
  equations in tables (CSTR 49) or both

o groff's fixed order does not accommodate tables in diagrams, which is
  certainly possible.

> The Version 7  
> UNIX versions of these tools (circa 1979) described in the "CSTR 49" 
> document you cite had several limitations (many related to having to 
> run in 64k of code space on a pdp 11/70), that don't apply to modern 
> troff implementations.

How is that relevant?  The CSTR documents have been updated.  Moreover,
the primary consideration is the order which is necessary to produce
proper formatted output; the order that works for tables in diagrams is
different from the order that works for diagrams in tables, in a
mutually exclusive relationship (i.e. there is no order that will cover
both cases).

From: blilly at erols.com (Bruce Lilly)
Date: Tue Jan  3 16:22:58 2006
Subject: regarding your comments on proposed media type text/troff' to Informational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Thu April 14 2005 22:49, Keith Moore wrote:
> [cc'ed to ietf-types list, which per RFC 2048 is where this document 
> should be reviewed.]

Pre-draft discussions and earlier drafts have been discussed on
ietf-types; as the current draft is in Last Call, I've restored
copies to the IESG list.

> Bruce,
> 
> I raise this concern both because this was something that was discussed 
> extensively in the ietf-822 working group that created MIME, and also 
> because we've seen far too many security holes result from giving the 
> sender a way to choose what program to run on the recipient's system 

The "process" parameter is explicitly *NOT* "giving the sender a way to
choose what program to run on the recipient's system".  It is a way for
the sender to suggest a recommended processing sequence to the human
recipient.  N.B. "suggest", "recommended", and "human".

> (usually by ignoring the content-type parameter and paying attention to 
> the application-specific filename suffix).

There is a detailed discussion of suffixes (a.k.a. "extensions") in the
draft.

> Even if we don't think  
> troff will be used much, it sets a bad precedent to allow a new 
> content-type to specify something that we have ample experience to 
> indicate it's harmful.
> 
> RFC 2046 (section 4.5.1) even includes the following language, which 
> also appeared in RFCs 1341 and 1521:
> 
> >    To reduce the danger of transmitting rogue programs, it is strongly
> >    recommended that implementations NOT implement a path-search
> >    mechanism whereby an arbitrary program named in the Content-Type
> >    parameter (e.g., an "interpreter=" parameter) is found and executed
> >    using the message body as input.

I fully agree that implementations should take suitable precautions. I
would (and have in the draft) go farther and state that implementations
(w.r.t. text/troff) should not automatically process content other than
possibly stripping directives for presentation.  And there are some
specific additional recommendations for safe presentation whether or
not directives are stripped (e.g. precautions against control
characters). 

> now this is in a section related to the application/octet-stream 
> content-type, but the principle is the same - if you let the sender 
> choose what programs should be used to process the input, the 
> content-type label is effectively ignored.

Again, that's not what is being done.

> And the only difference  
> between an "interpreter" parameter and a "process" parameter is that 
> you're not only letting the sender specify the interpreter, you're 
> letting him specify the entire command line!

Either way, we're agreed that *implementations* should not automatically
execute such programs.

> I don't think it matters much if you say "don't directly execute the 
> process parameter" because the very purpose of the process parameter is 
> to tell the sender exactly what to type,

ITYM "recipient".  And it's a suggestion, not an imperative.

> and to allow the sender to  
> specify arbitrary preprocessing programs and arbitrary parameters to 
> those programs.

The intent is to specify the preprocessors and parameters which will
produce the output that the author intended, not arbitrary progams/
parameters.  Certainly the mechanism could be abused, just as sending
a plain text message ("social engineering") can be abused.

> Maybe recipients should know better than type  
> arbitrary commands specified by the sender, but there's ample 
> experience to suggest that most recipients don't have that kind of 
> expertise.

The nature of the text media type is that subtypes of that type are
(supposed to be) presentable to a user w/o processing of any type (as
discussed in some detail in the draft).  As with some other "rich" text
subtypes, the proposed text/troff may also be processed for improved
presentation (e.g. to produce hard copy).  The "process" parameter
merely provides hints for the recipient to perform such processing
*IF* the recipient decides to do so.

> Nor am I persuaded by the "sender must specify the order of 
> preprocessing" argument, as groff has options to specify which of 
> several preprocessors to use, and it seems to work fine.

At the risk of being repetitive, no, groff's limited facility is
inadequate:

o groff is not installed everywhere

o there are different versions of groff; some have no support for the
  grap preprocessor

o no version of groff up to the present one has support for either chem
  or dformat preprocessors, or for preprocessors such as the one for
  handling ABNF

o groff uses fixed order of preprocessing, with eqn last.  That fails
  miserably for documents with equations in graphs (CSTR 114) or with
  equations in tables (CSTR 49) or both

o groff's fixed order does not accommodate tables in diagrams, which is
  certainly possible.

> The Version 7  
> UNIX versions of these tools (circa 1979) described in the "CSTR 49" 
> document you cite had several limitations (many related to having to 
> run in 64k of code space on a pdp 11/70), that don't apply to modern 
> troff implementations.

How is that relevant?  The CSTR documents have been updated.  Moreover,
the primary consideration is the order which is necessary to produce
proper formatted output; the order that works for tables in diagrams is
different from the order that works for diagrams in tables, in a
mutually exclusive relationship (i.e. there is no order that will cover
both cases).

From: moore at cs.utk.edu (Keith Moore)
Date: Fri Apr 15 04:49:53 2005
Subject: regarding your comments on proposed media type text/troff' to Informational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

[cc'ed to ietf-types list, which per RFC 2048 is where this document 
should be reviewed.]

Bruce,

I raise this concern both because this was something that was discussed 
extensively in the ietf-822 working group that created MIME, and also 
because we've seen far too many security holes result from giving the 
sender a way to choose what program to run on the recipient's system 
(usually by ignoring the content-type parameter and paying attention to 
the application-specific filename suffix).  Even if we don't think 
troff will be used much, it sets a bad precedent to allow a new 
content-type to specify something that we have ample experience to 
indicate it's harmful.

RFC 2046 (section 4.5.1) even includes the following language, which 
also appeared in RFCs 1341 and 1521:

>    To reduce the danger of transmitting rogue programs, it is strongly
>    recommended that implementations NOT implement a path-search
>    mechanism whereby an arbitrary program named in the Content-Type
>    parameter (e.g., an "interpreter=" parameter) is found and executed
>    using the message body as input.

now this is in a section related to the application/octet-stream 
content-type, but the principle is the same - if you let the sender 
choose what programs should be used to process the input, the 
content-type label is effectively ignored.  And the only difference 
between an "interpreter" parameter and a "process" parameter is that 
you're not only letting the sender specify the interpreter, you're 
letting him specify the entire command line!

I don't think it matters much if you say "don't directly execute the 
process parameter" because the very purpose of the process parameter is 
to tell the sender exactly what to type, and to allow the sender to 
specify arbitrary preprocessing programs and arbitrary parameters to 
those programs.  Maybe recipients should know better than type 
arbitrary commands specified by the sender, but there's ample 
experience to suggest that most recipients don't have that kind of 
expertise.

Nor am I persuaded by the "sender must specify the order of 
preprocessing" argument, as groff has options to specify which of 
several preprocessors to use, and it seems to work fine.  The Version 7 
UNIX versions of these tools (circa 1979) described in the "CSTR 49" 
document you cite had several limitations (many related to having to 
run in 64k of code space on a pdp 11/70), that don't apply to modern 
troff implementations.

-Keith

On Apr 14, 2005, at 9:45 AM, Bruce Lilly wrote:

>> From: Keith Moore [mailto:[email-masked]]
>> Sent: Tuesday, April 12, 2005 4:14 PM
>> To: [email-masked]
>> Cc: [email-masked]
>> Subject: Re: Last Call: 'Media subtype registration for media type
>> text/troff' to Informational RFC
>
> Keith,
>
> Thanks for taking the time to review and comment on the draft.
>
> Before addressing your comments in detail, I would like to make some
> observations about troff source, text formatting, and MIME mechanisms:
>
> o some documents might be text only, others might include equations,
>   tables, graphs, line drawings, etc.  Complex documents might include
>   equations within tables (CSTR 49), equations within line drawings
>   (CSTR 114), and/or equations within graphs (CSTR 116), to name but a
>   few possible combinations.  Preprocessor order is dependent on such
>   document structure (as noted in CSTR 49); it is insufficient to know
>   which preprocessors to use, the order is critically important.
>
> o many preprocessors take command line arguments; one needs to know
>   not only which preprocessors to use, and in which order, but also
>   which command line arguments to supply to each preprocessor, and
>   in some cases the order of arguments matters.
>
> o troff provides a comment mechanism (as do most preprocessors); that
>   could be used (as noted in the draft) to convey human-readable
>   document processing instructions.
>
> o MIME provides for packaging related content (multipart/related
>   composite media type), so separate processing instructions (e.g.
>   in a Makefile) could be packaged with document source.
>
>> I recommend against publication of this document as an RFC,
>> unless and until it is revised to fix the following problem:
>>
>> section 4:
>>
>> the process parameter appears to be a security hole, as it would
>> allow the sender to specify commands to be executed on the recipient's
>> system.  while this is documented in the security considerations 
>> section,
>> it is unnecessary, and long experience with implementations that 
>> provide
>> similar capability (e.g. the ability to launch an arbitrary 
>> application
>> based on the file name suffix) indicates that significant harm can 
>> come
>> from allowing the sender of a message to specify actions to be taken
>> by the recipient's MUA.
>
> The intent of the "process" parameter is to provide a uniform mechanism
> (vs. ad-hoc source comments or packaging of separate instructions) for
> communicating formatting instructions from the human author to a human
> recipient.  Automated execution is strongly recommended against (I 
> could
> of course make that a "MUST NOT", but I am skeptical of the value of 
> RFC
> 2119 language in an Informational RFC and I am uncertain of the
> implications for non-MIME contexts (N.B. the registration procedure is
> being separated from MIME)).  Publication as a Standards Track RFC 
> rather
> than Informational might address the RFC 2119 language issue (I'm
> uncertain of what the procedural implications would be at this point).
>
>> furthermore the process parameter is unlikely to be used by the 
>> recipient
>> _unless_ its handling is automated, because most MUAs do not make it 
>> easy
>> to see the content-type parameters associated with an attachment.  so
>> the parameter as defined is more likely to do harm than good, and
>> it would set a bad precedent for other content-type definitions.
>
> Handling should rarely, if ever, be fully automatic.  In this specific
> case, handling could involve presentation of the recommended processing
> command line to a user for review and modification, with execution of
> the possibly-modified command line only upon user approval.  That's
> what I had in mind.  I could add text to that effect as an example of
> appropriate use of the parameter, but I am wary of delving too far into
> implementation details, particularly as this is a media type 
> registration
> and not a specification for particular types of human interfaces.
>
>> if anything I would make the process parameter a list of keywords:
>> pic, eqn, tbl, etc.  the keywords should not be treated as commands
>> by the recipient's system (and certainly should not be looked up in 
>> the
>> recipient's PATH), but rather as flags to be passed to a processor 
>> such
>> as groff that knows where to find these programs and in what order 
>> they
>> should be run.
>
> A mere list doesn't indicate ordering.  Keywords alone don't provide
> indication of (preprocessor/formatter) arguments.  Groff (specifically
> "grog"):
> a) isn't universally available
> b) guesses wrong. Example on the source for the draft under discussion:
>      marty:/data/information/RFCs/text-troff # grog dr*2.df
>      groff -p -ms draft-lilly-text-troff-02.df
>    That indicates pic but not dformat, and indicates the ms macro
>    package, which is incorrect.
> The author presumably knows the necessary processing steps; an expert
> recipient might be able to figure out processing steps. A standard
> mechanism for conveying knowledge from the author to recipient avoids
> trial-and-error guesswork, and that's the intent of the optional
> "process" parameter.  Because the parameter is optional, a sender
> always has the option of omitting it.
>
>> there is also a need to specify what macro package is used: e.g.
>> -ms, -me, etc.
>
> I chose command-line syntax for the process parameter as it is capable
> of concisely and unambiguously indicating the necessary information:
>
> o preprocessors, formatters, and postprocessors required
>
> o preprocessor, formatter, and postprocessor arguments
>
> o order of preprocessor invocation
>
>> actually the varied handling of troff (and TeX) documents is probably
>> the reason we never defined a content-type for either of these.
>
> Yes, the richness of the type is unique; I know of no other media types
> that are as flexible, and that poses some challenges for specification.
>
>> we
>> certainly considered doing so at the time the MIME documents were 
>> being
>> written, and we used these file formats as examples of content which,
>> when interpreted on a recipient's system, could cause security 
>> breaches.
>
> Almost all media types (including plain text, as noted in the draft 
> w.r.t.
> control characters) have security issues.  I think the issues with 
> troff
> source have been reasonably addressed in the draft; compare for example
> to the approved registration for type application/msword.
>
>> Keith
>
> Would clarification of the recommendation against automated processing
> and an example of appropriate handling of the "process" parameter
> (either with or w/o "MUST NOT") address your objections?
>
> Best regards,
>   Bruce Lilly

From: moore at cs.utk.edu (Keith Moore)
Date: Tue Jan  3 16:22:58 2006
Subject: regarding your comments on proposed media type text/troff' to Informational RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

[cc'ed to ietf-types list, which per RFC 2048 is where this document 
should be reviewed.]

Bruce,

I raise this concern both because this was something that was discussed 
extensively in the ietf-822 working group that created MIME, and also 
because we've seen far too many security holes result from giving the 
sender a way to choose what program to run on the recipient's system 
(usually by ignoring the content-type parameter and paying attention to 
the application-specific filename suffix).  Even if we don't think 
troff will be used much, it sets a bad precedent to allow a new 
content-type to specify something that we have ample experience to 
indicate it's harmful.

RFC 2046 (section 4.5.1) even includes the following language, which 
also appeared in RFCs 1341 and 1521:

>    To reduce the danger of transmitting rogue programs, it is strongly
>    recommended that implementations NOT implement a path-search
>    mechanism whereby an arbitrary program named in the Content-Type
>    parameter (e.g., an "interpreter=" parameter) is found and executed
>    using the message body as input.

now this is in a section related to the application/octet-stream 
content-type, but the principle is the same - if you let the sender 
choose what programs should be used to process the input, the 
content-type label is effectively ignored.  And the only difference 
between an "interpreter" parameter and a "process" parameter is that 
you're not only letting the sender specify the interpreter, you're 
letting him specify the entire command line!

I don't think it matters much if you say "don't directly execute the 
process parameter" because the very purpose of the process parameter is 
to tell the sender exactly what to type, and to allow the sender to 
specify arbitrary preprocessing programs and arbitrary parameters to 
those programs.  Maybe recipients should know better than type 
arbitrary commands specified by the sender, but there's ample 
experience to suggest that most recipients don't have that kind of 
expertise.

Nor am I persuaded by the "sender must specify the order of 
preprocessing" argument, as groff has options to specify which of 
several preprocessors to use, and it seems to work fine.  The Version 7 
UNIX versions of these tools (circa 1979) described in the "CSTR 49" 
document you cite had several limitations (many related to having to 
run in 64k of code space on a pdp 11/70), that don't apply to modern 
troff implementations.

-Keith

On Apr 14, 2005, at 9:45 AM, Bruce Lilly wrote:

>> From: Keith Moore [mailto:[email-masked]]
>> Sent: Tuesday, April 12, 2005 4:14 PM
>> To: [email-masked]
>> Cc: [email-masked]
>> Subject: Re: Last Call: 'Media subtype registration for media type
>> text/troff' to Informational RFC
>
> Keith,
>
> Thanks for taking the time to review and comment on the draft.
>
> Before addressing your comments in detail, I would like to make some
> observations about troff source, text formatting, and MIME mechanisms:
>
> o some documents might be text only, others might include equations,
>   tables, graphs, line drawings, etc.  Complex documents might include
>   equations within tables (CSTR 49), equations within line drawings
>   (CSTR 114), and/or equations within graphs (CSTR 116), to name but a
>   few possible combinations.  Preprocessor order is dependent on such
>   document structure (as noted in CSTR 49); it is insufficient to know
>   which preprocessors to use, the order is critically important.
>
> o many preprocessors take command line arguments; one needs to know
>   not only which preprocessors to use, and in which order, but also
>   which command line arguments to supply to each preprocessor, and
>   in some cases the order of arguments matters.
>
> o troff provides a comment mechanism (as do most preprocessors); that
>   could be used (as noted in the draft) to convey human-readable
>   document processing instructions.
>
> o MIME provides for packaging related content (multipart/related
>   composite media type), so separate processing instructions (e.g.
>   in a Makefile) could be packaged with document source.
>
>> I recommend against publication of this document as an RFC,
>> unless and until it is revised to fix the following problem:
>>
>> section 4:
>>
>> the process parameter appears to be a security hole, as it would
>> allow the sender to specify commands to be executed on the recipient's
>> system.  while this is documented in the security considerations 
>> section,
>> it is unnecessary, and long experience with implementations that 
>> provide
>> similar capability (e.g. the ability to launch an arbitrary 
>> application
>> based on the file name suffix) indicates that significant harm can 
>> come
>> from allowing the sender of a message to specify actions to be taken
>> by the recipient's MUA.
>
> The intent of the "process" parameter is to provide a uniform mechanism
> (vs. ad-hoc source comments or packaging of separate instructions) for
> communicating formatting instructions from the human author to a human
> recipient.  Automated execution is strongly recommended against (I 
> could
> of course make that a "MUST NOT", but I am skeptical of the value of 
> RFC
> 2119 language in an Informational RFC and I am uncertain of the
> implications for non-MIME contexts (N.B. the registration procedure is
> being separated from MIME)).  Publication as a Standards Track RFC 
> rather
> than Informational might address the RFC 2119 language issue (I'm
> uncertain of what the procedural implications would be at this point).
>
>> furthermore the process parameter is unlikely to be used by the 
>> recipient
>> _unless_ its handling is automated, because most MUAs do not make it 
>> easy
>> to see the content-type parameters associated with an attachment.  so
>> the parameter as defined is more likely to do harm than good, and
>> it would set a bad precedent for other content-type definitions.
>
> Handling should rarely, if ever, be fully automatic.  In this specific
> case, handling could involve presentation of the recommended processing
> command line to a user for review and modification, with execution of
> the possibly-modified command line only upon user approval.  That's
> what I had in mind.  I could add text to that effect as an example of
> appropriate use of the parameter, but I am wary of delving too far into
> implementation details, particularly as this is a media type 
> registration
> and not a specification for particular types of human interfaces.
>
>> if anything I would make the process parameter a list of keywords:
>> pic, eqn, tbl, etc.  the keywords should not be treated as commands
>> by the recipient's system (and certainly should not be looked up in 
>> the
>> recipient's PATH), but rather as flags to be passed to a processor 
>> such
>> as groff that knows where to find these programs and in what order 
>> they
>> should be run.
>
> A mere list doesn't indicate ordering.  Keywords alone don't provide
> indication of (preprocessor/formatter) arguments.  Groff (specifically
> "grog"):
> a) isn't universally available
> b) guesses wrong. Example on the source for the draft under discussion:
>      marty:/data/information/RFCs/text-troff # grog dr*2.df
>      groff -p -ms draft-lilly-text-troff-02.df
>    That indicates pic but not dformat, and indicates the ms macro
>    package, which is incorrect.
> The author presumably knows the necessary processing steps; an expert
> recipient might be able to figure out processing steps. A standard
> mechanism for conveying knowledge from the author to recipient avoids
> trial-and-error guesswork, and that's the intent of the optional
> "process" parameter.  Because the parameter is optional, a sender
> always has the option of omitting it.
>
>> there is also a need to specify what macro package is used: e.g.
>> -ms, -me, etc.
>
> I chose command-line syntax for the process parameter as it is capable
> of concisely and unambiguously indicating the necessary information:
>
> o preprocessors, formatters, and postprocessors required
>
> o preprocessor, formatter, and postprocessor arguments
>
> o order of preprocessor invocation
>
>> actually the varied handling of troff (and TeX) documents is probably
>> the reason we never defined a content-type for either of these.
>
> Yes, the richness of the type is unique; I know of no other media types
> that are as flexible, and that poses some challenges for specification.
>
>> we
>> certainly considered doing so at the time the MIME documents were 
>> being
>> written, and we used these file formats as examples of content which,
>> when interpreted on a recipient's system, could cause security 
>> breaches.
>
> Almost all media types (including plain text, as noted in the draft 
> w.r.t.
> control characters) have security issues.  I think the issues with 
> troff
> source have been reasonably addressed in the draft; compare for example
> to the approved registration for type application/msword.
>
>> Keith
>
> Would clarification of the recommendation against automated processing
> and an example of appropriate handling of the "process" parameter
> (either with or w/o "MUST NOT") address your objections?
>
> Best regards,
>   Bruce Lilly

From: mnot at mnot.net (Mark Nottingham)
Date: Tue Jan  3 16:22:58 2006
Subject: For review: application/atom+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Will get this in -08 and re-circulate when it's ready.

Thanks,

On Apr 7, 2005, at 4:45 AM, Scott Hollenbeck wrote:

> Mark,
>
> One thing I didn't catch earlier (sorry): the change controller for 
> types in
> the standards tree MUST be the IESG.  It would be more appropriate to 
> say
> it's the IETF community as described in RFC 2048 and the documents 
> that will
> soon obsolete 2048, but the IESG is the standards process gatekeeper so
> that's what we've been using.  We've also accepted text where people 
> have
> said something like "The <foo> working group as designated by the 
> IESG".
>
> -Scott-
>
>> -----Original Message-----
>> From: Mark Nottingham [mailto:[email-masked]]
>> Sent: Wednesday, April 06, 2005 11:41 PM
>> To: [email-masked]
>> Subject: For review: application/atom+xml
>>
>>
>> One of the deliverables of the ATOMPUB WG is an xml-based format for
>> Web syndication. Please review the proposed "application/atom+xml"
>> media type therein; the registration template can be found below, and
>> the complete draft is:
>>
>> http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-07.txt
>>
>> Regards,
>>
>> ---8<----
>>     An Atom Document, when serialized as XML 1.0, can be
>> identified with
>>     the following media type:
>>
>>     MIME media type name: application
>>     MIME subtype name: atom+xml
>>     Mandatory 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: Identical to those of
>> "application/xml" as
>>        described in [RFC3023], section 3.2.
>>     Security considerations: As defined in this specification.
>>        [[anchor59: update upon publication]]
>>        In addition, as this media type uses the "+xml" convention, it
>>        shares the same security considerations as described
>> in [RFC3023],
>>        section 10.
>>     Interoperability considerations: There are no known
>> interoperability
>>        issues.
>>     Published specification: This specification.  [[anchor60:
>> update upon
>>        publication]]
>>     Applications that use this media type: No known applications
>>        currently use this media type.
>>
>>     Additional information:
>>
>>     Magic number(s): As specified for "application/xml" in [RFC3023],
>>        section 3.2.
>>     File extension: .atom
>>     Fragment identifiers: As specified for "application/xml" in
>>        [RFC3023], section 5.
>>     Base URI: As specified in [RFC3023], section 6.
>>     Macintosh File Type code: TEXT
>>     Person and email address to contact for further information: Mark
>>        Nottingham <[email-masked]>
>>     Intended usage: COMMON
>>     Author/Change controller: This specification's author(s).
>>        [[anchor61: update upon publication]]
>> --->8---
>>
>>
>> --
>> Mark Nottingham     http://www.mnot.net/
>>
>>
>
>
>

--
Mark Nottingham     http://www.mnot.net/

From: liam at w3.org (Liam Quin)
Date: Tue Jan  3 16:22:58 2006
Subject: W3C Last Call and Media Type request for comments: XQuery and XQueryX
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Thu, Apr 07, 2005 at 11:06:49PM +0200, Bjoern Hoehrmann wrote:
> * Liam Quin wrote:
> >It lets people put XQuery documents on public Web servers that may
> >not be configured correctly.  But it's not clear that this is the
> >right approach.
> 
> What kind of misconfiguration did you have in mind here? Configured to
> use an incorrect charset parameter? That's then easily addressed by not
> having a charset parameter.

That might in fact be the best approach for us.  I'll take it up
internally, thanks!

> >We expect to add to it later.  Right now the specifications are new
> >enough (in terms of Process) that security implications have not
> >all been explored.  I'd welcome help in this area.  What sort of
> >additional text did you expect in this section?
> 
> http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-03.txt
> section 6 covers this
Note that date on that document is April 1st -- we'll be able to take 
it into account for the next publication, which I hope will be for
Candidate Recommendation.

On whether it should be normative within XQuery, I'll take it
up internally.

> it seems inconsistent with other W3C Technical Reports.
This process of registering MIME types is new, so we're
treading new ground here.

Thanks again for your help.

Liam

-- 
Liam Quin, W3C XML Activity Lead, http://www.w3.org/People/Quin/
http://www.holoweb.net/~liam/

From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Tue Jan  3 16:22:58 2006
Subject: W3C Last Call and Media Type request for comments: XQuery and XQueryX
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

* Liam Quin wrote:
>It lets people put XQuery documents on public Web servers that may
>not be configured correctly.  But it's not clear that this is the
>right approach.

What kind of misconfiguration did you have in mind here? Configured to
use an incorrect charset parameter? That's then easily addressed by not
having a charset parameter.

>We expect to add to it later.  Right now the specifications are new
>enough (in terms of Process) that security implications have not
>all been explored.  I'd welcome help in this area.  What sort of
>additional text did you expect in this section?

http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-03.txt
section 6 covers this. For example, it seems possible to construct a
query such that it loops indefinitely through infinite recursion, that's
probably something implementations should protect against.

>It's non-normative within the context of the XQueryX specification:
>an implementation does not need to support anything here in order
>to claim conformance.  If you do support application/xquery+xml though,
>this is how you must do it.

http://www.w3.org/TR/2005/WD-xquery-20050404/#id-conform-optional-features
is not marked non-normative, even though none of the features in that
section are required in order to claim conformance, so this principle
does not seem to be applied consistently; and it seems inconsistent
with other W3C Technical Reports.
-- 
Bj?rn H?hrmann ? mailto:[email-masked] ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 

From: liam at w3.org (Liam Quin)
Date: Tue Jan  3 16:22:58 2006
Subject: W3C Last Call and Media Type request for comments: XQuery and XQueryX
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Thu, Apr 07, 2005 at 10:28:58PM +0200, Bjoern Hoehrmann wrote:
[...]
>> If an XQuery document contains an encoding declaration, it overrides the
>> default encoding specified by the MIME charset parameter.
> 
> That's inconsistent with pretty much all other media types that allow a
> charset parameter. What's the point of having a charset parameter here?

It lets people put XQuery documents on public Web servers that may
not be configured correctly.  But it's not clear that this is the
right approach.  Thank you for the comment.

>> I.5 Charset Default Rules
>> 
>> XQuery documents use the Unicode character set and, by default, the
>> UTF-8 encoding.
> 
> That's incorrect then, it defaults to the character encoding specified
> in the charset parameter (which then defaults to UTF-8).

In the MIME context that's true -- so far XQueryX has mostly (entirely?)
been used offline, where there's no charset parameter.

Thanks for spotting this.

> >I.6 Security Considerations
[...]

> Compared to http://www.ietf.org/rfc/rfc2046.txt section 4.5.2 this seems
> very incomplete...

We expect to add to it later.  Right now the specifications are new
enough (in terms of Process) that security implications have not
all been explored.  I'd welcome help in this area.  What sort of
additional text did you expect in this section?

> >**** Registration for application/xquery+xml also at [4]
> >
> >C The application/xquery+xml Media Type (Non-Normative)
> 
> Non-Normative? Is there a normative version of this text?

It's non-normative within the context of the XQueryX specification:
an implementation does not need to support anything here in order
to claim conformance.  If you do support application/xquery+xml though,
this is how you must do it.

I hope that's clearer.  It's been difficult to see the balance between
making th documents stand alone and making them also work as part of a
larger specification.

Liam

-- 
Liam Quin, W3C XML Activity Lead, http://www.w3.org/People/Quin/
http://www.holoweb.net/~liam/

From: liam at w3.org ('Liam Quin')
Date: Thu Apr  7 22:39:24 2005
Subject: W3C Last Call and Media Type request for comments: XQuery andXQueryX
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Thu, Apr 07, 2005 at 01:34:26PM -0700, Larry Masinter wrote:
>  
> > I.4 Recognizing XQuery Files
> > 
> > An XQuery file may have the string xquery version "V.V" near the
> > beginning of the document, where "V.V" is a version number. Currently
> > the version number, if present, must be "1.0".
> 
> I can't figure this out. Is the string "xquery" appear,
> "xquery version 1.0", or something else? I think the quotes
> are misplaced.

The xquery version information looks like:
    xquery version "1.0";
or, for example,
    xquery version "1.0" encoding "utf-8";

It's clearer in the formatted version -- mea culpa, I should have
reformatted it I think.

Liam

-- 
Liam Quin, W3C XML Activity Lead, http://www.w3.org/People/Quin/
http://www.holoweb.net/~liam/
>From [email-masked]  Thu Apr  7 22:46:23 2005
From: liam at w3.org (Liam Quin)
Date: Thu Apr  7 22:46:32 2005
Subject: W3C Last Call and Media Type request for comments: XQuery and
	XQueryX
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Thu, Apr 07, 2005 at 10:28:58PM +0200, Bjoern Hoehrmann wrote:
[...]
>> If an XQuery document contains an encoding declaration, it overrides the
>> default encoding specified by the MIME charset parameter.
> 
> That's inconsistent with pretty much all other media types that allow a
> charset parameter. What's the point of having a charset parameter here?

It lets people put XQuery documents on public Web servers that may
not be configured correctly.  But it's not clear that this is the
right approach.  Thank you for the comment.

>> I.5 Charset Default Rules
>> 
>> XQuery documents use the Unicode character set and, by default, the
>> UTF-8 encoding.
> 
> That's incorrect then, it defaults to the character encoding specified
> in the charset parameter (which then defaults to UTF-8).

In the MIME context that's true -- so far XQueryX has mostly (entirely?)
been used offline, where there's no charset parameter.

Thanks for spotting this.

> >I.6 Security Considerations
[...]

> Compared to http://www.ietf.org/rfc/rfc2046.txt section 4.5.2 this seems
> very incomplete...

We expect to add to it later.  Right now the specifications are new
enough (in terms of Process) that security implications have not
all been explored.  I'd welcome help in this area.  What sort of
additional text did you expect in this section?

> >**** Registration for application/xquery+xml also at [4]
> >
> >C The application/xquery+xml Media Type (Non-Normative)
> 
> Non-Normative? Is there a normative version of this text?

It's non-normative within the context of the XQueryX specification:
an implementation does not need to support anything here in order
to claim conformance.  If you do support application/xquery+xml though,
this is how you must do it.

I hope that's clearer.  It's been difficult to see the balance between
making th documents stand alone and making them also work as part of a
larger specification.

Liam

-- 
Liam Quin, W3C XML Activity Lead, http://www.w3.org/People/Quin/
http://www.holoweb.net/~liam/
>From [email-masked]  Thu Apr  7 23:06:49 2005
From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Thu Apr  7 23:06:37 2005
Subject: W3C Last Call and Media Type request for comments: XQuery and
	XQueryX
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

* Liam Quin wrote:
>It lets people put XQuery documents on public Web servers that may
>not be configured correctly.  But it's not clear that this is the
>right approach.

What kind of misconfiguration did you have in mind here? Configured to
use an incorrect charset parameter? That's then easily addressed by not
having a charset parameter.

>We expect to add to it later.  Right now the specifications are new
>enough (in terms of Process) that security implications have not
>all been explored.  I'd welcome help in this area.  What sort of
>additional text did you expect in this section?

http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-03.txt
section 6 covers this. For example, it seems possible to construct a
query such that it loops indefinitely through infinite recursion, that's
probably something implementations should protect against.

>It's non-normative within the context of the XQueryX specification:
>an implementation does not need to support anything here in order
>to claim conformance.  If you do support application/xquery+xml though,
>this is how you must do it.

http://www.w3.org/TR/2005/WD-xquery-20050404/#id-conform-optional-features
is not marked non-normative, even though none of the features in that
section are required in order to claim conformance, so this principle
does not seem to be applied consistently; and it seems inconsistent
with other W3C Technical Reports.
-- 
Bj?rn H?hrmann ? mailto:[email-masked] ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 
>From [email-masked]  Thu Apr  7 23:13:58 2005
From: liam at w3.org (Liam Quin)
Date: Thu Apr  7 23:14:07 2005
Subject: W3C Last Call and Media Type request for comments: XQuery and
	XQueryX
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Thu, Apr 07, 2005 at 11:06:49PM +0200, Bjoern Hoehrmann wrote:
> * Liam Quin wrote:
> >It lets people put XQuery documents on public Web servers that may
> >not be configured correctly.  But it's not clear that this is the
> >right approach.
> 
> What kind of misconfiguration did you have in mind here? Configured to
> use an incorrect charset parameter? That's then easily addressed by not
> having a charset parameter.

That might in fact be the best approach for us.  I'll take it up
internally, thanks!

> >We expect to add to it later.  Right now the specifications are new
> >enough (in terms of Process) that security implications have not
> >all been explored.  I'd welcome help in this area.  What sort of
> >additional text did you expect in this section?
> 
> http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-03.txt
> section 6 covers this
Note that date on that document is April 1st -- we'll be able to take 
it into account for the next publication, which I hope will be for
Candidate Recommendation.

On whether it should be normative within XQuery, I'll take it
up internally.

> it seems inconsistent with other W3C Technical Reports.
This process of registering MIME types is new, so we're
treading new ground here.

Thanks again for your help.

Liam

-- 
Liam Quin, W3C XML Activity Lead, http://www.w3.org/People/Quin/
http://www.holoweb.net/~liam/
>From [email-masked]  Fri Apr  8 02:20:39 2005
From: mnot at mnot.net (Mark Nottingham)
Date: Fri Apr  8 02:20:53 2005
Subject: For review: application/atom+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Will get this in -08 and re-circulate when it's ready.

Thanks,

On Apr 7, 2005, at 4:45 AM, Scott Hollenbeck wrote:

> Mark,
>
> One thing I didn't catch earlier (sorry): the change controller for 
> types in
> the standards tree MUST be the IESG.  It would be more appropriate to 
> say
> it's the IETF community as described in RFC 2048 and the documents 
> that will
> soon obsolete 2048, but the IESG is the standards process gatekeeper so
> that's what we've been using.  We've also accepted text where people 
> have
> said something like "The <foo> working group as designated by the 
> IESG".
>
> -Scott-
>
>> -----Original Message-----
>> From: Mark Nottingham [mailto:[email-masked]]
>> Sent: Wednesday, April 06, 2005 11:41 PM
>> To: [email-masked]
>> Subject: For review: application/atom+xml
>>
>>
>> One of the deliverables of the ATOMPUB WG is an xml-based format for
>> Web syndication. Please review the proposed "application/atom+xml"
>> media type therein; the registration template can be found below, and
>> the complete draft is:
>>
>> http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-07.txt
>>
>> Regards,
>>
>> ---8<----
>>     An Atom Document, when serialized as XML 1.0, can be
>> identified with
>>     the following media type:
>>
>>     MIME media type name: application
>>     MIME subtype name: atom+xml
>>     Mandatory 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: Identical to those of
>> "application/xml" as
>>        described in [RFC3023], section 3.2.
>>     Security considerations: As defined in this specification.
>>        [[anchor59: update upon publication]]
>>        In addition, as this media type uses the "+xml" convention, it
>>        shares the same security considerations as described
>> in [RFC3023],
>>        section 10.
>>     Interoperability considerations: There are no known
>> interoperability
>>        issues.
>>     Published specification: This specification.  [[anchor60:
>> update upon
>>        publication]]
>>     Applications that use this media type: No known applications
>>        currently use this media type.
>>
>>     Additional information:
>>
>>     Magic number(s): As specified for "application/xml" in [RFC3023],
>>        section 3.2.
>>     File extension: .atom
>>     Fragment identifiers: As specified for "application/xml" in
>>        [RFC3023], section 5.
>>     Base URI: As specified in [RFC3023], section 6.
>>     Macintosh File Type code: TEXT
>>     Person and email address to contact for further information: Mark
>>        Nottingham <[email-masked]>
>>     Intended usage: COMMON
>>     Author/Change controller: This specification's author(s).
>>        [[anchor61: update upon publication]]
>> --->8---
>>
>>
>> --
>> Mark Nottingham     http://www.mnot.net/
>>
>>
>
>
>

--
Mark Nottingham     http://www.mnot.net/

From: liam at w3.org ('Liam Quin')
Date: Tue Jan  3 16:22:58 2006
Subject: W3C Last Call and Media Type request for comments: XQuery andXQueryX
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Thu, Apr 07, 2005 at 01:34:26PM -0700, Larry Masinter wrote:
>  
> > I.4 Recognizing XQuery Files
> > 
> > An XQuery file may have the string xquery version "V.V" near the
> > beginning of the document, where "V.V" is a version number. Currently
> > the version number, if present, must be "1.0".
> 
> I can't figure this out. Is the string "xquery" appear,
> "xquery version 1.0", or something else? I think the quotes
> are misplaced.

The xquery version information looks like:
    xquery version "1.0";
or, for example,
    xquery version "1.0" encoding "utf-8";

It's clearer in the formatted version -- mea culpa, I should have
reformatted it I think.

Liam

-- 
Liam Quin, W3C XML Activity Lead, http://www.w3.org/People/Quin/
http://www.holoweb.net/~liam/

From: LMM at acm.org (Larry Masinter)
Date: Tue Jan  3 16:22:58 2006
Subject: W3C Last Call and Media Type request for comments: XQuery andXQueryX
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> I.4 Recognizing XQuery Files
> 
> An XQuery file may have the string xquery version "V.V" near the
> beginning of the document, where "V.V" is a version number. Currently
> the version number, if present, must be "1.0".

I can't figure this out. Is the string "xquery" appear,
"xquery version 1.0", or something else? I think the quotes
are misplaced.

From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Tue Jan  3 16:22:58 2006
Subject: W3C Last Call and Media Type request for comments: XQuery and XQueryX
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

* Liam Quin wrote:
>I.2 Registration of MIME Media Type application/xquery

>Optional parameters: charset
>
>The syntax of XQuery is expressed in Unicode but may be written with any
>Unicode-compatible character encoding, including UTF-8 or UTF-16, or
>transported as US-ASCII or Latin-1 with Unicode characters outside the
>range of the given encoding represented using an XML-style &#xddd;
>syntax.

>If an XQuery document contains an encoding declaration, it overrides the
>default encoding specified by the MIME charset parameter.

That's inconsistent with pretty much all other media types that allow a
charset parameter. What's the point of having a charset parameter here?

>I.5 Charset Default Rules
>
>XQuery documents use the Unicode character set and, by default, the
>UTF-8 encoding.

That's incorrect then, it defaults to the character encoding specified
in the charset parameter (which then defaults to UTF-8).

>I.6 Security Considerations
>
>Queries written in XQuery may cause arbitrary URIs to be dereferenced.
>Therefore, the security issues of [Uniform Resource Locators (URL)]
>Section 6 should be considered. In addition, the contents of file: URIs
>can in some cases be accessed, processed and returned as results.
>
>Furthermore, because the XQuery language permits extensions, it is
>possible that application/xquery may describe content that has security
>implications beyond those described here.
>
>The XML Query Working group is working on a facility to allow XQuery
>expressions to be used to create and update persistent data. Untrusted
>queries should not be given write access to data.

Compared to http://www.ietf.org/rfc/rfc2046.txt section 4.5.2 this seems
very incomplete...

>**** Registration for application/xquery+xml also at [4]
>
>C The application/xquery+xml Media Type (Non-Normative)

Non-Normative? Is there a normative version of this text?
-- 
Bj?rn H?hrmann ? mailto:[email-masked] ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 

From: liam at w3.org (Liam Quin)
Date: Tue Jan  3 16:22:58 2006
Subject: W3C Last Call and Media Type request for comments: XQuery and XQueryX
Message-ID: <[email-masked]>

[
 Notes:
 (1) - I'm trying to follow a new procedure here.  Becasue not
 everything is in place, the documents I refer to probably don't
 have perfect wording.  The documentation on the process was released
 after the documents were frozen for Last Call, but we can make
 any needed changes for the next round of publication.  I see
 that we failed to define the correct syntax for parameters, and would
 welcome comments on any other areas wheer we need to improve.

 (2) The following text will be inserted in the next published versions
 of the documents:
    This registration is for community review and will be (or has
    been) submitted to the IESG for review, approval, and
    registration with IANA.

 (3) We are using Bugzilla to track comments on these documents;
 comments on these MIME-related pats of the documents may be made
 on the ietf-types mailing list or in Bugzilla.  See the individual
 documents and their respective "Status of this Document" sections for
 further information.

 - Liam
]

In accordance with the draft Media Type Specifications and
Registration Procedures [1], and on behalf of the W3C XML Query
Working Group [2], I hereby give notice that W3C has published
two specifications at the stage "Last Call Working Draft" which
each incorporate definitions of a standards-tree MIME media type,
as allowed for in section 3.1 of [1], and request comments on
these definitions.

The types and subtypes are
    application/xquery
	defined in "XQuery 1.0: An XML Query Language" [3]
	optional parameter: charset
    application/xquery+xml
	defined in "XML Syntax for XQuery 1.0 (XQueryX)" [4]
	optional parameter: charset

**** Registration for application/xquery also at [3]

I The application/xquery Media Type (Non-Normative)
---------------------------------------------------

This Appendix specifies the media type for XQuery Version 1.0. XQuery is
a language for querying over collections of data from XML data sources,
as specified in the main body of this document.

I.1 Introduction
----------------

This document, together with its normative references, defines the
language XQuery Version 1.0. This Appendix provides information about
the application/xquery media type, which is intended to be used for
transmitting queries written in the XQuery language.

This document was prepared by members of the W3C XML Query Working
Group. Please send comments to public-qt-comments [at] w3.org, a public
mailing list with archives at
http://lists.w3.org/Archives/Public/public-qt-comments.

I.2 Registration of MIME Media Type application/xquery
------------------------------------------------------

MIME media type name: application

MIME subtype name: xquery

Required parameters: none

Optional parameters: charset

The syntax of XQuery is expressed in Unicode but may be written with any
Unicode-compatible character encoding, including UTF-8 or UTF-16, or
transported as US-ASCII or Latin-1 with Unicode characters outside the
range of the given encoding represented using an XML-style &#xddd;
syntax.

I.2.1 Interoperability Considerations

None known.

I.2.2 Applications Using this Media Type

The public XQuery Web page lists more than two dozen implementations of
the XQuery language, both proprietary and open source.

This new media type is being registered to allow for deployment of
XQuery on the World Wide Web.

I.2.3 File Extensions

The most common file extensions in use for XQuery are .xq and .xquery.

The appropriate Macintosh file type code is TEXT.

I.2.4 Intended Usage

The intended usage of this media type is for interchange of XQuery
expressions.

I.2.5 Author/Change Controller

XQuery was produced by, and is maintained by, the World Wide Web
Consortium's XML Query Working Group. The W3C has change control over
this specification.

I.3 Encoding Considerations

For use with transports that are not 8-bit clean, quoted-printable
encoding is recommended since the XQuery syntax itself uses the
US-ASCII-compatible subset of Unicode.

An XQuery document may contain an encoding declaration as part of its
version declaration:
    xquery version "1.0" encoding "utf-8";

If an XQuery document contains an encoding declaration, it overrides the
default encoding specified by the MIME charset parameter.

I.4 Recognizing XQuery Files

An XQuery file may have the string xquery version "V.V" near the
beginning of the document, where "V.V" is a version number. Currently
the version number, if present, must be "1.0".

I.5 Charset Default Rules

XQuery documents use the Unicode character set and, by default, the
UTF-8 encoding.

I.6 Security Considerations

Queries written in XQuery may cause arbitrary URIs to be dereferenced.
Therefore, the security issues of [Uniform Resource Locators (URL)]
Section 6 should be considered. In addition, the contents of file: URIs
can in some cases be accessed, processed and returned as results.

Furthermore, because the XQuery language permits extensions, it is
possible that application/xquery may describe content that has security
implications beyond those described here.

The XML Query Working group is working on a facility to allow XQuery
expressions to be used to create and update persistent data. Untrusted
queries should not be given write access to data.

**** Registration for application/xquery+xml also at [4]

C The application/xquery+xml Media Type (Non-Normative)
-------------------------------------------------------

This Appendix specifies the media type for XQueryX Version 1.0. XQueryX
is the XML syntax of a language, XQuery, for querying over data from XML
data sources, as specified in [XQuery 1.0: An XML Query Language].

C.1 Introduction
----------------

This document, together with its normative references, defines the XML
syntax for the XML Query language XQuery Version 1.0. This Appendix
specifies the application/xquery+xml media type, which is intended to be
used for transmitting queries expressed in the XQueryX syntax.

This document was prepared by members of the W3C XML Query Working
Group. Please send comments to public-qt-comments [at] w3.org, a public
mailing list with archives at
http://lists.w3.org/Archives/Public/public-qt-comments.
C.2 Registration of MIME Media Type application/xquery+xml

MIME media type name: application

MIME subtype name: xquery+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].

C.2.1 Encoding Considerations

The considerations as specified in RFC 3023 [XMLMIME] also hold for
'application/xquery+xml'.

C.2.2 Fragment Identifiers

For documents labeled as 'application/xquery+xml', fragment identifiers
are handled as specified in RFC 3023 [XMLMIME].

C.2.3 Restrictions on usage

The intended usage of this media type is for interchange of XQueryX
expressions.

C.2.4 Security Considerations

Queries written in XQueryX may cause arbitrary URIs to be dereferenced.
Therefore, the security issues of [Uniform Resource Locators (URL)]
Section 6 should be considered. In addition, the contents of file: URIs
can in some cases be accessed, processed and returned as results.

Furthermore, because the XQuery language (and thus the XQueryX language)
permits extensions, it is possible that application/xquery+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 arise.

The XML Query Working group is working on a facility to allow XQuery
(and thus XQueryX) expressions to be used to create and update
persistent data. Untrusted queries should not be given write access to
data.

C.2.5 Interoperability Considerations

See Section 5 ConformanceXQ.

C.2.6 Applications That Use This Media Type

The public XQuery Web page lists more than two dozen implementations of
the XQuery language, both proprietary and open source. Some of these are
known to support XQueryX.

This new media type is being registered to allow for deployment of
XQueryX on the World Wide Web.

There is no experimental, vendor specific, or personal tree predecessor
to "application/xquery+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 XQueryX 1.0 on the World Wide Web,
as a first class XML application.

C.2.7 Additional Information

C.2.7.1 Recognizing XQuery Files ("Magic Numbers")

Although no byte sequences can be counted on to consistently identify
XQueryX, XQueryX documents will have the sequence
"http://www.w3.org/yyyy/mm/XQueryX" to identify the XQueryX namespace
(where "yyyy" is exactly four decimal digits and "mm" is exactly two
decimal digits). This sequence will normally be found in a namespace
attribute of the first element in the document.

C.2.7.2 File Extensions

The most common file extension in use for XQueryX is .xqx.

C.2.7.3 Macintosh File Type Code(s)

The appropriate Macintosh file type code is TEXT.

C.2.8 Person and Email Address to Contact For Further Information

Jim Melton, Oracle Corp., jim.melton [at] oracle.com

C.2.9 Intended Usage

COMMON

C.2.10 Author/Change Controller

XQuery was produced by, and is maintained by, the World Wide Web
Consortium's XML Query Working Group. The W3C has change control over
this specification.

[1] http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-02.txt
[2] http://www.w3.org/XML/Query
[3] http://www.w3.org/TR/2005/WD-xquery-20050404/#id-mime-type
[4] http://www.w3.org/TR/2005/WD-xqueryx-20050404/#xqueryx-id-mime-type

-- 
Liam Quin, W3C XML Activity Lead, http://www.w3.org/People/Quin/
http://www.holoweb.net/~liam/

From: distobj at acm.org (Mark Baker)
Date: Thu Apr  7 21:22:13 2005
Subject: For review: application/atom+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Mark,

I think you might want to mention somewhere - probably under Interop
considerations - that application/atom+xml is already in use today with
"Atom 0.3", which is incompatible (AIUI) with the new atompub syntax
draft.

Cheers,

Mark.

On Wed, Apr 06, 2005 at 08:41:08PM -0700, Mark Nottingham wrote:
>    Interoperability considerations: There are no known interoperability
>       issues.
[snip]

-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
>From [email-masked]  Thu Apr  7 22:01:51 2005
From: liam at w3.org (Liam Quin)
Date: Thu Apr  7 22:02:00 2005
Subject: W3C Last Call and Media Type request for comments: XQuery and
	XQueryX
Message-ID: <[email-masked]>

[
 Notes:
 (1) - I'm trying to follow a new procedure here.  Becasue not
 everything is in place, the documents I refer to probably don't
 have perfect wording.  The documentation on the process was released
 after the documents were frozen for Last Call, but we can make
 any needed changes for the next round of publication.  I see
 that we failed to define the correct syntax for parameters, and would
 welcome comments on any other areas wheer we need to improve.

 (2) The following text will be inserted in the next published versions
 of the documents:
    This registration is for community review and will be (or has
    been) submitted to the IESG for review, approval, and
    registration with IANA.

 (3) We are using Bugzilla to track comments on these documents;
 comments on these MIME-related pats of the documents may be made
 on the ietf-types mailing list or in Bugzilla.  See the individual
 documents and their respective "Status of this Document" sections for
 further information.

 - Liam
]

In accordance with the draft Media Type Specifications and
Registration Procedures [1], and on behalf of the W3C XML Query
Working Group [2], I hereby give notice that W3C has published
two specifications at the stage "Last Call Working Draft" which
each incorporate definitions of a standards-tree MIME media type,
as allowed for in section 3.1 of [1], and request comments on
these definitions.

The types and subtypes are
    application/xquery
	defined in "XQuery 1.0: An XML Query Language" [3]
	optional parameter: charset
    application/xquery+xml
	defined in "XML Syntax for XQuery 1.0 (XQueryX)" [4]
	optional parameter: charset

**** Registration for application/xquery also at [3]

I The application/xquery Media Type (Non-Normative)
---------------------------------------------------

This Appendix specifies the media type for XQuery Version 1.0. XQuery is
a language for querying over collections of data from XML data sources,
as specified in the main body of this document.

I.1 Introduction
----------------

This document, together with its normative references, defines the
language XQuery Version 1.0. This Appendix provides information about
the application/xquery media type, which is intended to be used for
transmitting queries written in the XQuery language.

This document was prepared by members of the W3C XML Query Working
Group. Please send comments to public-qt-comments [at] w3.org, a public
mailing list with archives at
http://lists.w3.org/Archives/Public/public-qt-comments.

I.2 Registration of MIME Media Type application/xquery
------------------------------------------------------

MIME media type name: application

MIME subtype name: xquery

Required parameters: none

Optional parameters: charset

The syntax of XQuery is expressed in Unicode but may be written with any
Unicode-compatible character encoding, including UTF-8 or UTF-16, or
transported as US-ASCII or Latin-1 with Unicode characters outside the
range of the given encoding represented using an XML-style &#xddd;
syntax.

I.2.1 Interoperability Considerations

None known.

I.2.2 Applications Using this Media Type

The public XQuery Web page lists more than two dozen implementations of
the XQuery language, both proprietary and open source.

This new media type is being registered to allow for deployment of
XQuery on the World Wide Web.

I.2.3 File Extensions

The most common file extensions in use for XQuery are .xq and .xquery.

The appropriate Macintosh file type code is TEXT.

I.2.4 Intended Usage

The intended usage of this media type is for interchange of XQuery
expressions.

I.2.5 Author/Change Controller

XQuery was produced by, and is maintained by, the World Wide Web
Consortium's XML Query Working Group. The W3C has change control over
this specification.

I.3 Encoding Considerations

For use with transports that are not 8-bit clean, quoted-printable
encoding is recommended since the XQuery syntax itself uses the
US-ASCII-compatible subset of Unicode.

An XQuery document may contain an encoding declaration as part of its
version declaration:
    xquery version "1.0" encoding "utf-8";

If an XQuery document contains an encoding declaration, it overrides the
default encoding specified by the MIME charset parameter.

I.4 Recognizing XQuery Files

An XQuery file may have the string xquery version "V.V" near the
beginning of the document, where "V.V" is a version number. Currently
the version number, if present, must be "1.0".

I.5 Charset Default Rules

XQuery documents use the Unicode character set and, by default, the
UTF-8 encoding.

I.6 Security Considerations

Queries written in XQuery may cause arbitrary URIs to be dereferenced.
Therefore, the security issues of [Uniform Resource Locators (URL)]
Section 6 should be considered. In addition, the contents of file: URIs
can in some cases be accessed, processed and returned as results.

Furthermore, because the XQuery language permits extensions, it is
possible that application/xquery may describe content that has security
implications beyond those described here.

The XML Query Working group is working on a facility to allow XQuery
expressions to be used to create and update persistent data. Untrusted
queries should not be given write access to data.

**** Registration for application/xquery+xml also at [4]

C The application/xquery+xml Media Type (Non-Normative)
-------------------------------------------------------

This Appendix specifies the media type for XQueryX Version 1.0. XQueryX
is the XML syntax of a language, XQuery, for querying over data from XML
data sources, as specified in [XQuery 1.0: An XML Query Language].

C.1 Introduction
----------------

This document, together with its normative references, defines the XML
syntax for the XML Query language XQuery Version 1.0. This Appendix
specifies the application/xquery+xml media type, which is intended to be
used for transmitting queries expressed in the XQueryX syntax.

This document was prepared by members of the W3C XML Query Working
Group. Please send comments to public-qt-comments [at] w3.org, a public
mailing list with archives at
http://lists.w3.org/Archives/Public/public-qt-comments.
C.2 Registration of MIME Media Type application/xquery+xml

MIME media type name: application

MIME subtype name: xquery+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].

C.2.1 Encoding Considerations

The considerations as specified in RFC 3023 [XMLMIME] also hold for
'application/xquery+xml'.

C.2.2 Fragment Identifiers

For documents labeled as 'application/xquery+xml', fragment identifiers
are handled as specified in RFC 3023 [XMLMIME].

C.2.3 Restrictions on usage

The intended usage of this media type is for interchange of XQueryX
expressions.

C.2.4 Security Considerations

Queries written in XQueryX may cause arbitrary URIs to be dereferenced.
Therefore, the security issues of [Uniform Resource Locators (URL)]
Section 6 should be considered. In addition, the contents of file: URIs
can in some cases be accessed, processed and returned as results.

Furthermore, because the XQuery language (and thus the XQueryX language)
permits extensions, it is possible that application/xquery+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 arise.

The XML Query Working group is working on a facility to allow XQuery
(and thus XQueryX) expressions to be used to create and update
persistent data. Untrusted queries should not be given write access to
data.

C.2.5 Interoperability Considerations

See Section 5 ConformanceXQ.

C.2.6 Applications That Use This Media Type

The public XQuery Web page lists more than two dozen implementations of
the XQuery language, both proprietary and open source. Some of these are
known to support XQueryX.

This new media type is being registered to allow for deployment of
XQueryX on the World Wide Web.

There is no experimental, vendor specific, or personal tree predecessor
to "application/xquery+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 XQueryX 1.0 on the World Wide Web,
as a first class XML application.

C.2.7 Additional Information

C.2.7.1 Recognizing XQuery Files ("Magic Numbers")

Although no byte sequences can be counted on to consistently identify
XQueryX, XQueryX documents will have the sequence
"http://www.w3.org/yyyy/mm/XQueryX" to identify the XQueryX namespace
(where "yyyy" is exactly four decimal digits and "mm" is exactly two
decimal digits). This sequence will normally be found in a namespace
attribute of the first element in the document.

C.2.7.2 File Extensions

The most common file extension in use for XQueryX is .xqx.

C.2.7.3 Macintosh File Type Code(s)

The appropriate Macintosh file type code is TEXT.

C.2.8 Person and Email Address to Contact For Further Information

Jim Melton, Oracle Corp., jim.melton [at] oracle.com

C.2.9 Intended Usage

COMMON

C.2.10 Author/Change Controller

XQuery was produced by, and is maintained by, the World Wide Web
Consortium's XML Query Working Group. The W3C has change control over
this specification.

[1] http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-02.txt
[2] http://www.w3.org/XML/Query
[3] http://www.w3.org/TR/2005/WD-xquery-20050404/#id-mime-type
[4] http://www.w3.org/TR/2005/WD-xqueryx-20050404/#xqueryx-id-mime-type

-- 
Liam Quin, W3C XML Activity Lead, http://www.w3.org/People/Quin/
http://www.holoweb.net/~liam/
>From [email-masked]  Thu Apr  7 22:28:58 2005
From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Thu Apr  7 22:28:48 2005
Subject: W3C Last Call and Media Type request for comments: XQuery and
	XQueryX
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

* Liam Quin wrote:
>I.2 Registration of MIME Media Type application/xquery

>Optional parameters: charset
>
>The syntax of XQuery is expressed in Unicode but may be written with any
>Unicode-compatible character encoding, including UTF-8 or UTF-16, or
>transported as US-ASCII or Latin-1 with Unicode characters outside the
>range of the given encoding represented using an XML-style &#xddd;
>syntax.

>If an XQuery document contains an encoding declaration, it overrides the
>default encoding specified by the MIME charset parameter.

That's inconsistent with pretty much all other media types that allow a
charset parameter. What's the point of having a charset parameter here?

>I.5 Charset Default Rules
>
>XQuery documents use the Unicode character set and, by default, the
>UTF-8 encoding.

That's incorrect then, it defaults to the character encoding specified
in the charset parameter (which then defaults to UTF-8).

>I.6 Security Considerations
>
>Queries written in XQuery may cause arbitrary URIs to be dereferenced.
>Therefore, the security issues of [Uniform Resource Locators (URL)]
>Section 6 should be considered. In addition, the contents of file: URIs
>can in some cases be accessed, processed and returned as results.
>
>Furthermore, because the XQuery language permits extensions, it is
>possible that application/xquery may describe content that has security
>implications beyond those described here.
>
>The XML Query Working group is working on a facility to allow XQuery
>expressions to be used to create and update persistent data. Untrusted
>queries should not be given write access to data.

Compared to http://www.ietf.org/rfc/rfc2046.txt section 4.5.2 this seems
very incomplete...

>**** Registration for application/xquery+xml also at [4]
>
>C The application/xquery+xml Media Type (Non-Normative)

Non-Normative? Is there a normative version of this text?
-- 
Bj?rn H?hrmann ? mailto:[email-masked] ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 
>From [email-masked]  Thu Apr  7 22:34:26 2005
From: LMM at acm.org (Larry Masinter)
Date: Thu Apr  7 22:34:51 2005
Subject: W3C Last Call and Media Type request for comments: XQuery
 andXQueryX
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> I.4 Recognizing XQuery Files
> 
> An XQuery file may have the string xquery version "V.V" near the
> beginning of the document, where "V.V" is a version number. Currently
> the version number, if present, must be "1.0".

I can't figure this out. Is the string "xquery" appear,
"xquery version 1.0", or something else? I think the quotes
are misplaced.

From: distobj at acm.org (Mark Baker)
Date: Tue Jan  3 16:22:58 2006
Subject: For review: application/atom+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Mark,

I think you might want to mention somewhere - probably under Interop
considerations - that application/atom+xml is already in use today with
"Atom 0.3", which is incompatible (AIUI) with the new atompub syntax
draft.

Cheers,

Mark.

On Wed, Apr 06, 2005 at 08:41:08PM -0700, Mark Nottingham wrote:
>    Interoperability considerations: There are no known interoperability
>       issues.
[snip]

-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

From: sah at 428cobrajet.net (Scott Hollenbeck)
Date: Thu Apr  7 13:45:41 2005
Subject: For review: application/atom+xml
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Mark,

One thing I didn't catch earlier (sorry): the change controller for types in
the standards tree MUST be the IESG.  It would be more appropriate to say
it's the IETF community as described in RFC 2048 and the documents that will
soon obsolete 2048, but the IESG is the standards process gatekeeper so
that's what we've been using.  We've also accepted text where people have
said something like "The <foo> working group as designated by the IESG".

-Scott-

> -----Original Message-----
> From: Mark Nottingham [mailto:[email-masked]] 
> Sent: Wednesday, April 06, 2005 11:41 PM
> To: [email-masked]
> Subject: For review: application/atom+xml
> 
> 
> One of the deliverables of the ATOMPUB WG is an xml-based format for 
> Web syndication. Please review the proposed "application/atom+xml" 
> media type therein; the registration template can be found below, and 
> the complete draft is:
>    
> http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-07.txt
> 
> Regards,
> 
> ---8<----
>     An Atom Document, when serialized as XML 1.0, can be 
> identified with
>     the following media type:
> 
>     MIME media type name: application
>     MIME subtype name: atom+xml
>     Mandatory 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: Identical to those of 
> "application/xml" as
>        described in [RFC3023], section 3.2.
>     Security considerations: As defined in this specification.
>        [[anchor59: update upon publication]]
>        In addition, as this media type uses the "+xml" convention, it
>        shares the same security considerations as described 
> in [RFC3023],
>        section 10.
>     Interoperability considerations: There are no known 
> interoperability
>        issues.
>     Published specification: This specification.  [[anchor60: 
> update upon
>        publication]]
>     Applications that use this media type: No known applications
>        currently use this media type.
> 
>     Additional information:
> 
>     Magic number(s): As specified for "application/xml" in [RFC3023],
>        section 3.2.
>     File extension: .atom
>     Fragment identifiers: As specified for "application/xml" in
>        [RFC3023], section 5.
>     Base URI: As specified in [RFC3023], section 6.
>     Macintosh File Type code: TEXT
>     Person and email address to contact for further information: Mark
>        Nottingham <[email-masked]>
>     Intended usage: COMMON
>     Author/Change controller: This specification's author(s).
>        [[anchor61: update upon publication]]
> --->8---
> 
> 
> --
> Mark Nottingham     http://www.mnot.net/
> 
> 

From: sah at 428cobrajet.net (Scott Hollenbeck)
Date: Tue Jan  3 16:22:58 2006
Subject: For review: application/atom+xml
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Mark,

One thing I didn't catch earlier (sorry): the change controller for types in
the standards tree MUST be the IESG.  It would be more appropriate to say
it's the IETF community as described in RFC 2048 and the documents that will
soon obsolete 2048, but the IESG is the standards process gatekeeper so
that's what we've been using.  We've also accepted text where people have
said something like "The <foo> working group as designated by the IESG".

-Scott-

> -----Original Message-----
> From: Mark Nottingham [mailto:[email-masked]] 
> Sent: Wednesday, April 06, 2005 11:41 PM
> To: [email-masked]
> Subject: For review: application/atom+xml
> 
> 
> One of the deliverables of the ATOMPUB WG is an xml-based format for 
> Web syndication. Please review the proposed "application/atom+xml" 
> media type therein; the registration template can be found below, and 
> the complete draft is:
>    
> http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-07.txt
> 
> Regards,
> 
> ---8<----
>     An Atom Document, when serialized as XML 1.0, can be 
> identified with
>     the following media type:
> 
>     MIME media type name: application
>     MIME subtype name: atom+xml
>     Mandatory 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: Identical to those of 
> "application/xml" as
>        described in [RFC3023], section 3.2.
>     Security considerations: As defined in this specification.
>        [[anchor59: update upon publication]]
>        In addition, as this media type uses the "+xml" convention, it
>        shares the same security considerations as described 
> in [RFC3023],
>        section 10.
>     Interoperability considerations: There are no known 
> interoperability
>        issues.
>     Published specification: This specification.  [[anchor60: 
> update upon
>        publication]]
>     Applications that use this media type: No known applications
>        currently use this media type.
> 
>     Additional information:
> 
>     Magic number(s): As specified for "application/xml" in [RFC3023],
>        section 3.2.
>     File extension: .atom
>     Fragment identifiers: As specified for "application/xml" in
>        [RFC3023], section 5.
>     Base URI: As specified in [RFC3023], section 6.
>     Macintosh File Type code: TEXT
>     Person and email address to contact for further information: Mark
>        Nottingham <[email-masked]>
>     Intended usage: COMMON
>     Author/Change controller: This specification's author(s).
>        [[anchor61: update upon publication]]
> --->8---
> 
> 
> --
> Mark Nottingham     http://www.mnot.net/
> 
> 

From: mnot at mnot.net (Mark Nottingham)
Date: Thu Apr  7 05:41:22 2005
Subject: For review: application/atom+xml
Message-ID: <[email-masked]>

One of the deliverables of the ATOMPUB WG is an xml-based format for 
Web syndication. Please review the proposed "application/atom+xml" 
media type therein; the registration template can be found below, and 
the complete draft is:
   http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-07.txt

Regards,

---8<----
    An Atom Document, when serialized as XML 1.0, can be identified with
    the following media type:

    MIME media type name: application
    MIME subtype name: atom+xml
    Mandatory 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: Identical to those of "application/xml" as
       described in [RFC3023], section 3.2.
    Security considerations: As defined in this specification.
       [[anchor59: update upon publication]]
       In addition, as this media type uses the "+xml" convention, it
       shares the same security considerations as described in [RFC3023],
       section 10.
    Interoperability considerations: There are no known interoperability
       issues.
    Published specification: This specification.  [[anchor60: update upon
       publication]]
    Applications that use this media type: No known applications
       currently use this media type.

    Additional information:

    Magic number(s): As specified for "application/xml" in [RFC3023],
       section 3.2.
    File extension: .atom
    Fragment identifiers: As specified for "application/xml" in
       [RFC3023], section 5.
    Base URI: As specified in [RFC3023], section 6.
    Macintosh File Type code: TEXT
    Person and email address to contact for further information: Mark
       Nottingham <[email-masked]>
    Intended usage: COMMON
    Author/Change controller: This specification's author(s).
       [[anchor61: update upon publication]]
--->8---

--
Mark Nottingham     http://www.mnot.net/

From: mnot at mnot.net (Mark Nottingham)
Date: Tue Jan  3 16:22:58 2006
Subject: For review: application/atom+xml
Message-ID: <[email-masked]>

One of the deliverables of the ATOMPUB WG is an xml-based format for 
Web syndication. Please review the proposed "application/atom+xml" 
media type therein; the registration template can be found below, and 
the complete draft is:
   http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-07.txt

Regards,

---8<----
    An Atom Document, when serialized as XML 1.0, can be identified with
    the following media type:

    MIME media type name: application
    MIME subtype name: atom+xml
    Mandatory 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: Identical to those of "application/xml" as
       described in [RFC3023], section 3.2.
    Security considerations: As defined in this specification.
       [[anchor59: update upon publication]]
       In addition, as this media type uses the "+xml" convention, it
       shares the same security considerations as described in [RFC3023],
       section 10.
    Interoperability considerations: There are no known interoperability
       issues.
    Published specification: This specification.  [[anchor60: update upon
       publication]]
    Applications that use this media type: No known applications
       currently use this media type.

    Additional information:

    Magic number(s): As specified for "application/xml" in [RFC3023],
       section 3.2.
    File extension: .atom
    Fragment identifiers: As specified for "application/xml" in
       [RFC3023], section 5.
    Base URI: As specified in [RFC3023], section 6.
    Macintosh File Type code: TEXT
    Person and email address to contact for further information: Mark
       Nottingham <[email-masked]>
    Intended usage: COMMON
    Author/Change controller: This specification's author(s).
       [[anchor61: update upon publication]]
--->8---

--
Mark Nottingham     http://www.mnot.net/

From: mccobb at us.ibm.com (Gerald McCobb)
Date: Tue Apr  5 18:39:47 2005
Subject: Request for comments regarding draft-mccobb-xplusv-media-type-01
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

In response to your previous comments (thanks) I submitted 
draft-mccobb-xplusv-media-type-02.txt to [email-masked].  Please 
review and thanks in advance:

Network Working Group                                          G. McCobb
Internet-Draft                                           IBM Corporation
Expires: Oct. 1, 2005                                      April 1, 2005

                XHTML+Voice - application/xhtml+voice+xml
                    draft-mccobb-xplusv-media-type-02

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance 
   with RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six 
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as 
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved

Abstract

   This document describes the registration of the MIME sub-type
   application/xhtml+voice+xml.  This sub-type is intended for use as a
   media descriptor for XHTML+Voice multimodal language documents.  The
   XHTML+Voice 1.2 language specification is maintained by the VoiceXML
   Forum at <http://www.voicexml.org/specs/multimodal/x+v/12/>.

1.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119
   [RFC2119].

McCobb                   Expires Oct. 1, 2005                   [Page 1]

Internet-Draft   XHTML+Voice - application/xhtml+voice+xml April 1, 2005

2. Introduction

   XHTML+Voice is a member of the XHTML family of document types, as
   specified by XHTML Modularization [XHTMLMOD].  XHTML+Voice extends
   XHTML 1.1 [XHTML11] with a modularized subset of VoiceXML 2.0
   [VXML20], XML Events [XMLEVNTS], and a few extensions to both XHTML
   and VoiceXML 2.0.  XHTML 1.1, VoiceXML 2.0 and XML Events are W3C
   Recommendations.

   The language integration defined by XHTML+Voice supports all modules
   defined by XHTML Modularization, and adds voice interaction to XHTML
   elements to enable multimodal applications.  The defined document
   type for XHTML+Voice is XHTML Host language document type conformant.

   XHTML+Voice 1.2 [XPLUSV12] is maintained by the VoiceXML Forum, at
   URI location <http://www.voicexml.org/specs/multimodal/x+v/12/>.

2.1 application/xhtml+voice+xml Usage

   The application/xhtml+voice+xml media type is intended to be a media
   descriptor for XHTML+Voice multimodal documents. Multimodal browsers
   have special processing requirements for XHTML+Voice documents, such
   as running a voice browser component, and support for the DOM Level
   2 Event Model [DOM2EV] and XML Events [XMLEVNTS].

   This media type registration is not intended for email usage.

3. IANA Registration

      To: [email-masked]
      Subject: Registration of Standard MIME media type 
               application/xhtml+voice+xml

      MIME media type name: application

      MIME subtype name: xhtml+voice+xml

      Required parameters: none

      Optional parameters:

        charset:  has the same semantics as the charset parameter of the
                  "application/xml" media type specified in [RFC3023].

      Encoding considerations: 7bit.  See section 4 of [RFC3236].

      Security considerations:
 
   XHTML+Voice is an extension of XHTML and has the same security issues

McCobb                   Expires Oct. 1, 2005                   [Page 2]

Internet-Draft   XHTML+Voice - application/xhtml+voice+xml April 1, 2005

   as XHTML.  These include interpreting anchors and forms in XHTML
   documents, and scripting languages and other dynamic interactive
   capabilities.  See section 7 of [RFC3236].

   In addition, the scripting language can be accessed by both the XHTML
   and the VoiceXML 2.0 markup embedded in the XHTML+Voice document.
   See section 1.3.1.5 of [XPLUSV12].

      Interoperability considerations :

   Because XHTML+Voice is built upon W3C standard recommendations, it is
   designed to be interoperable across a wide range of platforms and
   client devices.  Because the extensions to XHTML are identified by
   their namespaces, all browsers that have namespace support can run an
   XHTML+Voice document as an XHTML document without voice interaction.
 
     Published specification:

         The latest published version of XHTML+Voice is [XPLUSV12].

      Applications which use this media type:

         XHTML+Voice documents are intended to be deployed on the World
         Wide Web and rendered by multimodal browsers that support the
         visual and voice modes of interaction.  Because XHTML+Voice is
         an application of XML, authors can expect XHTML+Voice user
         agents to be conformant XML 1.0 [XML] processors.  See section
         2 of [RFC3236].

      Additional information:

         Magic number(s):  There is no single string that is always
             present.
         File extension(s): mxml, xhvml, xvml, xvm
         Macintosh File Type Code(s): TEXT

      Person & email address to contact for further information:

         Gerald M. McCobb
         [email-masked]

      Intended usage: COMMON

      Author/Change controller: Gerald McCobb

      Further information:

4. Fragment Identifiers

   See section 3 of [RFC3236].  Following [RFC3236], fragment

McCobb                   Expires Oct. 1, 2005                   [Page 3]

Internet-Draft   XHTML+Voice - application/xhtml+voice+xml April 1, 2005

   identifiers for XHTML+Voice documents designate the element with the
   corresponding ID attribute value (see [XML] section 3.3.1).

   While XHTML+Voice adds new ID attributes with fragment identifier
   namespaces that are not in the same namespace as XHTML, the fragment
   identifiers are processed in the same namespace as the ID attribute's
   namespace.

5. Recognizing XHTML+Voice files

   Because XHTML+Voice is XML, an XHTML+Voice document [optionally]
   starts with an XML declaration which begins with "<?xml" and has a
   DOCTYPE declaration "<!DOCTYPE html".  XHTML+Voice 1.2 has the
   following DOCTYPE declaration:
 
   <!DOCTYPE html PUBLIC "-//VoiceXML Forum//DTD XHTML+Voice 1.2//EN"
"http://www.voicexml.org/specs/multimodal/x+v/12/dtd/xhtml+voice12.dtd">
 
   Because XHTML+Voice is in the XHTML family of languages, the root
   element of an XHTML+Voice document is 'html' and '<html' can be found
   near the top of the document. 

6. Security Considerations

   Security considerations for this media type are discussed in the MIME
   type registration that appears in section 3.

7. Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2396]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifiers (URI): Generic Syntax", RFC 2396,
              August 1998.

   [RFC3023]  Murata, M., St. Laurent, S., and D. Kohn, "XML Media
              Types", RFC 3023, January 2001.

   [RFC3236]  Baker, M., Stark, P., "The 'application/xhtml+xml' Media
              Type", RFC 3236, January 2002.

   [XML]      "Extensible Markup Language (XML) 1.0", W3C
              Recommendation.  Available at <http://www.w3.org/TR/REC-
              xml> (or <http://www.w3.org/TR/2000/REC-xml-20001006>).

   [XHTMLMOD] "Modularization of XHTML," 10 April, 2001, Murray Altheim,
              Frank Boumphrey, Sam Dooley, et al, W3C Recommendation, 
              http://www.w3.org/TR/xhtml-modularization/

McCobb                   Expires Oct. 1, 2005                   [Page 4]

Internet-Draft   XHTML+Voice - application/xhtml+voice+xml April 1, 2005

   [XHTML11]  "XHTML 1.1 - Module-based XHTML," 31 May 2001, Murray 
              Altheim, Shane McCarron, W3C Recommendation,
              http://www.w3.org/TR/xhtml11/.

   [DOM2EV]   "Document Object Model Level 2 Events Specification," 
              Tom Pixley, 2000.  W3C Recommendation,
              http://www.w3.org/TR/DOM-Level-2-Events/.

   [XMLEVNTS] "XML Events - An events syntax for XML", Steven
              Pemberton, T. V. Raman, and Shane McCarron, 2002.  W3C
              Recommendation, http://www.w3.org/TR/xml-events/.
   [XPLUSV12] "XHTML+Voice Profile 1.2," 16 March 2004, J. Axelsson,
              et al, http://www.voicexml.org/specs/multimodal/x+v/12/

   [VXML20]   "Voice Extensible Markup Language (VoiceXML)," 16 March
              2004, Scott McGlashan et al, W3C Recommendation,
              http://www.w3.org/TR/voicexml20/.

8. Authors' Address

   Gerald M. McCobb
   IBM Corporation
   8051 Congress Avenue, Office 2019
   Boca Raton, Florida 33487
   USA

   Phone: +1-561-862-2109
   Fax:   +1-561-862-3922
   EMail: [email-masked]

9. Full Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on 
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 
   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

   Intellectual Property

   The IETF takes no position regarding the validity or scope of any

McCobb                   Expires Oct. 1, 2005                   [Page 5]

Internet-Draft   XHTML+Voice - application/xhtml+voice+xml April 1, 2005

   Intellectual Property Rights or other rights that might be claimed 
   to pertain to the implementation or use of the technology described 
   in this document or the extent to which any license under such 
   rights might or might not be available; nor does it represent that 
   it has made any independent effort to identify any such rights. 
   Information on the procedures with respect to rights in RFC 
   documents can be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use
   of such proprietary rights by implementers or users of this 
   specification can be obtained from the IETF on-line IPR repository 
   at http://www.ietf.org/ipr. 

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   [email-masked].

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Mccobb                   Expires May 15, 2005                   [Page 6]

Regards,
Gerald McCobb
IBM
8051 Congress Avenue
Boca Raton, FL 33487
Tel. # 561-862-2109 T/L 975-2109

Bjoern Hoehrmann <[email-masked]>
03/26/2005 06:06 PM
 
        To:     Gerald McCobb/Boca Raton/IBM@IBMUS
        cc:     [email-masked], [email-masked]
        Subject:        Re: Request for comments regarding 
draft-mccobb-xplusv-media-type-01

* Gerald McCobb wrote:
>2.1 application/xhtml+voice+xml Usage
>
>   The application/xhtml+voice+xml media type is intended to be a media
>   descriptor for XHTML+Voice documents.
>
>   This media type registration is not intended for email usage.

The draft does not really explain why there is a need for such a
type in the first place; why don't you use application/xhtml+xml?

>      Optional parameters:
>   version:  refers to the XHTML+Voice language version in the document.
>             Acceptable values are 1.0, 1.1, and 1.2 (default).

What are the processing requirements for this parameter?

>   charset:  has the same meaning as the text/html media type.  See
>   section 2 of [RFC 2854].

A word seems to be missing here. It is not really clear why the draft
refers to RFC 2854 rather than RFC 3023 or RFC 3236. 

>      Security considerations:
> 
>   XHTML+Voice is an extension of XHTML and has the same security issues
>   as XHTML.  These include interpreting anchors and forms in HTML
>   documents, and scripting languages and other dynamic interactive
>   capabilities.  See section 7 of [RFC 2854].

So the extensions to XHTML have no security considerations?

>         File extension(s): html, htm, mxml, xvml

I don't think .html and .htm should be listed here, they are already in
common use for application/xhtml+xml and text/html.

>4. Fragment Identifiers
>
>   See section 3 of [RFC 2854].

It is unclear what this means, RFC 2854 and RFC 3236 have inconsistent
rules for fragment identifiers and XHTML+Voice adds new ID attributes
so that the fragment identifier namespaces are different.

>6. Security Considerations
>
>   Security considerations for this media type are discussed in the MIME
>   type registration that appears in section 4.

Section 4 has no security considerations...

>7. References

The draft should be clear about which of these references are
informative and which normative.
-- 
Bj?rn H?hrmann ? mailto:[email-masked] ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20050405/4146e3bd/attachment-0001.html
>From [email-masked]  Wed Apr  6 14:48:40 2005
From: mankin at psg.com (Allison Mankin)
Date: Wed Apr  6 14:48:47 2005
Subject: Transport Area requests Media Type review for audio/BV16 and
	audio/BV32
Message-ID: <[email-masked]>

The Transport Area requests a Media Type review for the proposed
new types audio/BV16 and audio/BV32, intended for the IETF tree,
for Proposed Standard, specified in 
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-04.txt.

We know of the following needed change:

The reference RFC for maxptime is RFC 3267, not 2327.

Please provide any comments before 21 April 2005.

Thanks,

Allison

From: mccobb at us.ibm.com (Gerald McCobb)
Date: Tue Jan  3 16:22:58 2006
Subject: Request for comments regarding draft-mccobb-xplusv-media-type-01
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

In response to your previous comments (thanks) I submitted 
draft-mccobb-xplusv-media-type-02.txt to [email-masked].  Please 
review and thanks in advance:

Network Working Group                                          G. McCobb
Internet-Draft                                           IBM Corporation
Expires: Oct. 1, 2005                                      April 1, 2005

                XHTML+Voice - application/xhtml+voice+xml
                    draft-mccobb-xplusv-media-type-02

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance 
   with RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six 
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as 
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved

Abstract

   This document describes the registration of the MIME sub-type
   application/xhtml+voice+xml.  This sub-type is intended for use as a
   media descriptor for XHTML+Voice multimodal language documents.  The
   XHTML+Voice 1.2 language specification is maintained by the VoiceXML
   Forum at <http://www.voicexml.org/specs/multimodal/x+v/12/>.

1.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119
   [RFC2119].

McCobb                   Expires Oct. 1, 2005                   [Page 1]

Internet-Draft   XHTML+Voice - application/xhtml+voice+xml April 1, 2005

2. Introduction

   XHTML+Voice is a member of the XHTML family of document types, as
   specified by XHTML Modularization [XHTMLMOD].  XHTML+Voice extends
   XHTML 1.1 [XHTML11] with a modularized subset of VoiceXML 2.0
   [VXML20], XML Events [XMLEVNTS], and a few extensions to both XHTML
   and VoiceXML 2.0.  XHTML 1.1, VoiceXML 2.0 and XML Events are W3C
   Recommendations.

   The language integration defined by XHTML+Voice supports all modules
   defined by XHTML Modularization, and adds voice interaction to XHTML
   elements to enable multimodal applications.  The defined document
   type for XHTML+Voice is XHTML Host language document type conformant.

   XHTML+Voice 1.2 [XPLUSV12] is maintained by the VoiceXML Forum, at
   URI location <http://www.voicexml.org/specs/multimodal/x+v/12/>.

2.1 application/xhtml+voice+xml Usage

   The application/xhtml+voice+xml media type is intended to be a media
   descriptor for XHTML+Voice multimodal documents. Multimodal browsers
   have special processing requirements for XHTML+Voice documents, such
   as running a voice browser component, and support for the DOM Level
   2 Event Model [DOM2EV] and XML Events [XMLEVNTS].

   This media type registration is not intended for email usage.

3. IANA Registration

      To: [email-masked]
      Subject: Registration of Standard MIME media type 
               application/xhtml+voice+xml

      MIME media type name: application

      MIME subtype name: xhtml+voice+xml

      Required parameters: none

      Optional parameters:

        charset:  has the same semantics as the charset parameter of the
                  "application/xml" media type specified in [RFC3023].

      Encoding considerations: 7bit.  See section 4 of [RFC3236].

      Security considerations:
 
   XHTML+Voice is an extension of XHTML and has the same security issues

McCobb                   Expires Oct. 1, 2005                   [Page 2]

Internet-Draft   XHTML+Voice - application/xhtml+voice+xml April 1, 2005

   as XHTML.  These include interpreting anchors and forms in XHTML
   documents, and scripting languages and other dynamic interactive
   capabilities.  See section 7 of [RFC3236].

   In addition, the scripting language can be accessed by both the XHTML
   and the VoiceXML 2.0 markup embedded in the XHTML+Voice document.
   See section 1.3.1.5 of [XPLUSV12].

      Interoperability considerations :

   Because XHTML+Voice is built upon W3C standard recommendations, it is
   designed to be interoperable across a wide range of platforms and
   client devices.  Because the extensions to XHTML are identified by
   their namespaces, all browsers that have namespace support can run an
   XHTML+Voice document as an XHTML document without voice interaction.
 
     Published specification:

         The latest published version of XHTML+Voice is [XPLUSV12].

      Applications which use this media type:

         XHTML+Voice documents are intended to be deployed on the World
         Wide Web and rendered by multimodal browsers that support the
         visual and voice modes of interaction.  Because XHTML+Voice is
         an application of XML, authors can expect XHTML+Voice user
         agents to be conformant XML 1.0 [XML] processors.  See section
         2 of [RFC3236].

      Additional information:

         Magic number(s):  There is no single string that is always
             present.
         File extension(s): mxml, xhvml, xvml, xvm
         Macintosh File Type Code(s): TEXT

      Person & email address to contact for further information:

         Gerald M. McCobb
         [email-masked]

      Intended usage: COMMON

      Author/Change controller: Gerald McCobb

      Further information:

4. Fragment Identifiers

   See section 3 of [RFC3236].  Following [RFC3236], fragment

McCobb                   Expires Oct. 1, 2005                   [Page 3]

Internet-Draft   XHTML+Voice - application/xhtml+voice+xml April 1, 2005

   identifiers for XHTML+Voice documents designate the element with the
   corresponding ID attribute value (see [XML] section 3.3.1).

   While XHTML+Voice adds new ID attributes with fragment identifier
   namespaces that are not in the same namespace as XHTML, the fragment
   identifiers are processed in the same namespace as the ID attribute's
   namespace.

5. Recognizing XHTML+Voice files

   Because XHTML+Voice is XML, an XHTML+Voice document [optionally]
   starts with an XML declaration which begins with "<?xml" and has a
   DOCTYPE declaration "<!DOCTYPE html".  XHTML+Voice 1.2 has the
   following DOCTYPE declaration:
 
   <!DOCTYPE html PUBLIC "-//VoiceXML Forum//DTD XHTML+Voice 1.2//EN"
"http://www.voicexml.org/specs/multimodal/x+v/12/dtd/xhtml+voice12.dtd">
 
   Because XHTML+Voice is in the XHTML family of languages, the root
   element of an XHTML+Voice document is 'html' and '<html' can be found
   near the top of the document. 

6. Security Considerations

   Security considerations for this media type are discussed in the MIME
   type registration that appears in section 3.

7. Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2396]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifiers (URI): Generic Syntax", RFC 2396,
              August 1998.

   [RFC3023]  Murata, M., St. Laurent, S., and D. Kohn, "XML Media
              Types", RFC 3023, January 2001.

   [RFC3236]  Baker, M., Stark, P., "The 'application/xhtml+xml' Media
              Type", RFC 3236, January 2002.

   [XML]      "Extensible Markup Language (XML) 1.0", W3C
              Recommendation.  Available at <http://www.w3.org/TR/REC-
              xml> (or <http://www.w3.org/TR/2000/REC-xml-20001006>).

   [XHTMLMOD] "Modularization of XHTML," 10 April, 2001, Murray Altheim,
              Frank Boumphrey, Sam Dooley, et al, W3C Recommendation, 
              http://www.w3.org/TR/xhtml-modularization/

McCobb                   Expires Oct. 1, 2005                   [Page 4]

Internet-Draft   XHTML+Voice - application/xhtml+voice+xml April 1, 2005

   [XHTML11]  "XHTML 1.1 - Module-based XHTML," 31 May 2001, Murray 
              Altheim, Shane McCarron, W3C Recommendation,
              http://www.w3.org/TR/xhtml11/.

   [DOM2EV]   "Document Object Model Level 2 Events Specification," 
              Tom Pixley, 2000.  W3C Recommendation,
              http://www.w3.org/TR/DOM-Level-2-Events/.

   [XMLEVNTS] "XML Events - An events syntax for XML", Steven
              Pemberton, T. V. Raman, and Shane McCarron, 2002.  W3C
              Recommendation, http://www.w3.org/TR/xml-events/.
   [XPLUSV12] "XHTML+Voice Profile 1.2," 16 March 2004, J. Axelsson,
              et al, http://www.voicexml.org/specs/multimodal/x+v/12/

   [VXML20]   "Voice Extensible Markup Language (VoiceXML)," 16 March
              2004, Scott McGlashan et al, W3C Recommendation,
              http://www.w3.org/TR/voicexml20/.

8. Authors' Address

   Gerald M. McCobb
   IBM Corporation
   8051 Congress Avenue, Office 2019
   Boca Raton, Florida 33487
   USA

   Phone: +1-561-862-2109
   Fax:   +1-561-862-3922
   EMail: [email-masked]

9. Full Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on 
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 
   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

   Intellectual Property

   The IETF takes no position regarding the validity or scope of any

McCobb                   Expires Oct. 1, 2005                   [Page 5]

Internet-Draft   XHTML+Voice - application/xhtml+voice+xml April 1, 2005

   Intellectual Property Rights or other rights that might be claimed 
   to pertain to the implementation or use of the technology described 
   in this document or the extent to which any license under such 
   rights might or might not be available; nor does it represent that 
   it has made any independent effort to identify any such rights. 
   Information on the procedures with respect to rights in RFC 
   documents can be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use
   of such proprietary rights by implementers or users of this 
   specification can be obtained from the IETF on-line IPR repository 
   at http://www.ietf.org/ipr. 

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   [email-masked].

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Mccobb                   Expires May 15, 2005                   [Page 6]

Regards,
Gerald McCobb
IBM
8051 Congress Avenue
Boca Raton, FL 33487
Tel. # 561-862-2109 T/L 975-2109

Bjoern Hoehrmann <[email-masked]>
03/26/2005 06:06 PM
 
        To:     Gerald McCobb/Boca Raton/IBM@IBMUS
        cc:     [email-masked], [email-masked]
        Subject:        Re: Request for comments regarding 
draft-mccobb-xplusv-media-type-01

* Gerald McCobb wrote:
>2.1 application/xhtml+voice+xml Usage
>
>   The application/xhtml+voice+xml media type is intended to be a media
>   descriptor for XHTML+Voice documents.
>
>   This media type registration is not intended for email usage.

The draft does not really explain why there is a need for such a
type in the first place; why don't you use application/xhtml+xml?

>      Optional parameters:
>   version:  refers to the XHTML+Voice language version in the document.
>             Acceptable values are 1.0, 1.1, and 1.2 (default).

What are the processing requirements for this parameter?

>   charset:  has the same meaning as the text/html media type.  See
>   section 2 of [RFC 2854].

A word seems to be missing here. It is not really clear why the draft
refers to RFC 2854 rather than RFC 3023 or RFC 3236. 

>      Security considerations:
> 
>   XHTML+Voice is an extension of XHTML and has the same security issues
>   as XHTML.  These include interpreting anchors and forms in HTML
>   documents, and scripting languages and other dynamic interactive
>   capabilities.  See section 7 of [RFC 2854].

So the extensions to XHTML have no security considerations?

>         File extension(s): html, htm, mxml, xvml

I don't think .html and .htm should be listed here, they are already in
common use for application/xhtml+xml and text/html.

>4. Fragment Identifiers
>
>   See section 3 of [RFC 2854].

It is unclear what this means, RFC 2854 and RFC 3236 have inconsistent
rules for fragment identifiers and XHTML+Voice adds new ID attributes
so that the fragment identifier namespaces are different.

>6. Security Considerations
>
>   Security considerations for this media type are discussed in the MIME
>   type registration that appears in section 4.

Section 4 has no security considerations...

>7. References

The draft should be clear about which of these references are
informative and which normative.
-- 
Bj?rn H?hrmann ? mailto:[email-masked] ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/ietf-types/attachments/20050405/4146e3bd/attachment.html
>From [email-masked]  Wed Apr  6 14:48:40 2005
From: mankin at psg.com (Allison Mankin)
Date: Tue Jan  3 16:22:58 2006
Subject: Transport Area requests Media Type review for audio/BV16 and
	audio/BV32
Message-ID: <[email-masked]>

The Transport Area requests a Media Type review for the proposed
new types audio/BV16 and audio/BV32, intended for the IETF tree,
for Proposed Standard, specified in 
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-04.txt.

We know of the following needed change:

The reference RFC for maxptime is RFC 3267, not 2327.

Please provide any comments before 21 April 2005.

Thanks,

Allison

From: YakovS at solidmatrix.com (Yakov Shafranovich)
Date: Tue Apr  5 05:16:24 2005
Subject: Type 'text/csv', draft-04
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

One missed problem, we are upto -05:

http://www.shaftek.org/publications/drafts/mime-csv/draft-shafranovich-mime-csv-05.html 

http://www.shaftek.org/publications/drafts/mime-csv/draft-shafranovich-mime-csv-05.txt 

HTML and text diff of changes:

http://www.shaftek.org/publications/drafts/mime-csv/rfcdiff-04-to-05.html
http://www.shaftek.org/publications/drafts/mime-csv/diff-04-to-05.txt

Yakov

Yakov Shafranovich wrote:
> I posted a new version (-04) correcting the ABNF grammar in response to 
> IESG comments, adding a few clarifications and adding a new optional 
> "header" parameter to indicate the absence or presence of a header line. 
> Copies of the draft can be found below and the draft should post to the 
> IETF ID repository sometime Monday:
> 
> http://www.shaftek.org/publications/drafts/mime-csv/draft-shafranovich-mime-csv-04.html 
> 
> http://www.shaftek.org/publications/drafts/mime-csv/draft-shafranovich-mime-csv-04.txt 
> 
> 
> HTML and text diff of changes:
> 
> http://www.shaftek.org/publications/drafts/mime-csv/rfcdiff-03-to-04.html
> http://www.shaftek.org/publications/drafts/mime-csv/diff-03-to-04.txt
> 
> Yakov
> 
> 
> 
> 
> 
> 

From: YakovS at solidmatrix.com (Yakov Shafranovich)
Date: Tue Jan  3 16:22:57 2006
Subject: Type 'text/csv', draft-04
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

One missed problem, we are upto -05:

http://www.shaftek.org/publications/drafts/mime-csv/draft-shafranovich-mime-csv-05.html 

http://www.shaftek.org/publications/drafts/mime-csv/draft-shafranovich-mime-csv-05.txt 

HTML and text diff of changes:

http://www.shaftek.org/publications/drafts/mime-csv/rfcdiff-04-to-05.html
http://www.shaftek.org/publications/drafts/mime-csv/diff-04-to-05.txt

Yakov

Yakov Shafranovich wrote:
> I posted a new version (-04) correcting the ABNF grammar in response to 
> IESG comments, adding a few clarifications and adding a new optional 
> "header" parameter to indicate the absence or presence of a header line. 
> Copies of the draft can be found below and the draft should post to the 
> IETF ID repository sometime Monday:
> 
> http://www.shaftek.org/publications/drafts/mime-csv/draft-shafranovich-mime-csv-04.html 
> 
> http://www.shaftek.org/publications/drafts/mime-csv/draft-shafranovich-mime-csv-04.txt 
> 
> 
> HTML and text diff of changes:
> 
> http://www.shaftek.org/publications/drafts/mime-csv/rfcdiff-03-to-04.html
> http://www.shaftek.org/publications/drafts/mime-csv/diff-03-to-04.txt
> 
> Yakov
> 
> 
> 
> 
> 
> 

From: mf at w3.org (Max Froumentin)
Date: Mon Apr  4 14:03:21 2005
Subject: please review draft-froumentin-voice-mediatypes-00
Message-ID: <[email-masked]>

draft-froumentin-voice-mediatypes-00 contains the registration of 
the 6 media types of the W3C Speech Interface Framework
(including the following specifications: SSML, SRGS, CCXML, PLS and VoiceXML)

Draft available at
http://www.ietf.org/internet-drafts/draft-froumentin-voice-mediatypes-00.txt
and copied below.

Max Froumentin, W3C

Network Working Group                                      M. Froumentin
Internet-Draft                                                       W3C
Expires: September 2, 2005                                    March 2005

            The W3C Speech Interface Framework Media Types:
  application/voicexml+xml,  application/ssml+xml,  application/srgs,
  application/srgs+xml, application/ccxml+xml and application/pls+xml
                  draft-froumentin-voice-mediatypes-00

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 2, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document defines the media type for the languages of the W3C
   Speech Interface Framework: VoiceXML, SSML, SRGS, CCXML and PLS.

Froumentin              Expires September 2, 2005               [Page 1]

Internet-Draft    W3C Speech Interface Framework Media Types  March 2005

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Registration of application/voicexml+xml,
       application/ssml+xml, application/srgs+xml,
       application/ccxml+xml and application/pls+xml  . . . . . . . .  4
     2.1   Encoding considerations  . . . . . . . . . . . . . . . . .  4
     2.2   Interoperability considerations  . . . . . . . . . . . . .  4
     2.3   Published specifications . . . . . . . . . . . . . . . . .  4
     2.4   Applications which use these media types . . . . . . . . .  4
     2.5   Security Considerations  . . . . . . . . . . . . . . . . .  4
     2.6   Additional Information . . . . . . . . . . . . . . . . . .  5
       2.6.1   Magic numbers  . . . . . . . . . . . . . . . . . . . .  5
       2.6.2   File extensions  . . . . . . . . . . . . . . . . . . .  5
       2.6.3   Fragment identifiers . . . . . . . . . . . . . . . . .  5
       2.6.4   Macintosh File Type Code . . . . . . . . . . . . . . .  5
       2.6.5   Person & email address to contact for further
               information  . . . . . . . . . . . . . . . . . . . . .  5
       2.6.6   Intended usage . . . . . . . . . . . . . . . . . . . .  5
       2.6.7   Change Controller  . . . . . . . . . . . . . . . . . .  5
   3.  Registration of application/srgs . . . . . . . . . . . . . . .  7
     3.1   Encoding considerations  . . . . . . . . . . . . . . . . .  7
     3.2   Interoperability considerations  . . . . . . . . . . . . .  7
     3.3   Published specifications . . . . . . . . . . . . . . . . .  7
     3.4   Applications which use this media types  . . . . . . . . .  7
     3.5   Security Considerations  . . . . . . . . . . . . . . . . .  7
     3.6   Additional Information . . . . . . . . . . . . . . . . . .  7
       3.6.1   Magic numbers  . . . . . . . . . . . . . . . . . . . .  7
       3.6.2   File extensions  . . . . . . . . . . . . . . . . . . .  8
       3.6.3   Macintosh File Type Code . . . . . . . . . . . . . . .  8
       3.6.4   Person & email address to contact for further
               information  . . . . . . . . . . . . . . . . . . . . .  8
       3.6.5   Intended usage . . . . . . . . . . . . . . . . . . . .  8
       3.6.6   Change Controller  . . . . . . . . . . . . . . . . . .  8
   4.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  9
       Intellectual Property and Copyright Statements . . . . . . . . 10

Froumentin              Expires September 2, 2005               [Page 2]

Internet-Draft    W3C Speech Interface Framework Media Types  March 2005

1.  Introduction

   This specification defines the media types of the VoiceXML, SSML,
   SRGS, CCXML and PLS, the specifications of the W3C Speech Interface
   Platform

   VoiceXML is an XML language designed for creating audio dialogs that
   feature synthesized speech, digitized audio, recognition of spoken
   and DTMF key input, recording of spoken input, telephony, and mixed
   initiative conversations.  The associated media type defined in this
   document is "application/voicexml+xml".

   The Speech Synthesis Markup Language Specification (SSML) defines an
   XML-based markup language for assisting the generation of synthetic
   speech in Web and other applications.  The essential role of SSML is
   to provide authors of synthesizable content a standard way to control
   aspects of speech such as pronunciation, volume, pitch, rate, etc.
   across different synthesis-capable platforms.  The asociated media
   type defined in this document is "application/ssml+xml".

   The Speech Recognition Grammar Specification (SRGS) defines syntax
   for representing grammars for use in speech recognition so that
   developers can specify the words and patterns of words to be listened
   for by a speech recognizer.  The syntax of the grammar format exists
   in two forms, an Augmented BNF Form and an XML Form.  The respective
   media types defined in this document are "application/srgs" and
   "application/srgs+xml".

   The Call Control eXtensible Markup Language (CCXML) is an XML
   language designed to provide telephony call control support for
   dialog systems, such as VoiceXML.  The associated media type defined
   in this document is "application/ccxml+xml".

   The Pronunciation Lexicon Specification (PLS) defines an XML syntax
   for specifying pronunciation lexicons to be used by speech
   recognition and speech synthesis engines in voice browser
   applications.  The associated media type defined in this document is
   "application/pls+xml".

Froumentin              Expires September 2, 2005               [Page 3]

Internet-Draft    W3C Speech Interface Framework Media Types  March 2005

2.  Registration of application/voicexml+xml, application/ssml+xml,
   application/srgs+xml, application/ccxml+xml and application/pls+xml

      MIME media type name: application
      MIME subtype names: voicexml+xml, ssml+xml, srgs+xml, ccxml+xml,
      pls+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 RFC 3023 [RFC3023].

2.1  Encoding considerations

   Identical to those of "application/xml" as described in RFC 3023
   [RFC3023], section 3.2

2.2  Interoperability considerations

   There are no known interoperability issues.

2.3  Published specifications

      Voice Extensible Markup Language 2.0 [VoiceXML2.0]
      Voice Extensible Markup Language 2.1 [VoiceXML2.1]
      Speech Synthesis Markup Language (SSML) Version 1.0 [SSML]
      Speech Recognition Grammar Specification Version 1.0 [SRGS]
      Voice Browser Call Control: CCXML Version 1.0 [CCXML]
      Pronunciation Lexicon Specification (PLS) Version 1.0 [PLS]

2.4   Applications which use these media types

   Various W3C Speech Interface Platform implementations use these media
   types

2.5  Security Considerations

   Several instructions in the cited specifications may cause arbitrary
   URIs to be dereferenced.  In this case, the security issues of
   [RFC2396], section 7, should be considered.

   In addition, because of the extensibility features of those
   specifications, it is possible that the registered media types may
   describe content that has security implications beyond those
   described here.  However, if the processor follows only the normative
   semantics of the specifications, 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

Froumentin              Expires September 2, 2005               [Page 4]

Internet-Draft    W3C Speech Interface Framework Media Types  March 2005

   dispatched to other processors, would security issues potentially
   arise.  And in that case, they would fall outside the domain of this
   registration document.

2.6  Additional Information

2.6.1  Magic numbers

   Although no byte sequences can be counted on to always be present,
   XML MIME entities in ASCII-compatible charsets (including UTF-8)
   often begin with hexadecimal 3C 3F 78 6D 6C ("<?xml"), and those in
   UTF-16 often begin with hexadecimal FE FF 00 3C 00 3F 00 78 00 6D 00
   6C or FF FE 3C 00 3F 00 78 00 6D 00 6C 00 (the Byte Order Mark (BOM)
   followed by "<?xml").  For more information, see Appendix F of [XML].

2.6.2  File extensions

   VoiceXML files: .vxml

   SSML files: .ssml

   SRGS files (XML syntax): .grxml

   CCXML files: .ccxml

   PLS files: .pls

2.6.3  Fragment identifiers

   Identical to that of "application/xml" as described in RFC 3023
   [RFC3023], section 5.

2.6.4  Macintosh File Type Code

   "TEXT"

2.6.5  Person & email address to contact for further information

   World Wide Web Consortium <[email-masked]>

2.6.6  Intended usage

   COMMON

2.6.7  Change Controller

   The Speech Interface Framework specifications set is a work product
   of the World Wide Web Consortium's Voice Browser Working Group.  The

Froumentin              Expires September 2, 2005               [Page 5]

Internet-Draft    W3C Speech Interface Framework Media Types  March 2005

   W3C has change control over these specifications.

Froumentin              Expires September 2, 2005               [Page 6]

Internet-Draft    W3C Speech Interface Framework Media Types  March 2005

3.  Registration of application/srgs

      MIME media type name: application
      MIME subtype names: srgs
      Required parameters: none
      Optional parameters: none

3.1  Encoding considerations

   The ABNF Form of SRGS follows the character encoding handling defined
   for XML: an ABNF grammar processor must accept both the UTF-8 and
   UTF-16 encodings of ISO/IEC 10646 and may support other character
   encodings.

3.2  Interoperability considerations

   There are no known interoperability issues.

3.3  Published specifications

      Speech Recognition Grammar Specification Version 1.0 [SRGS]

3.4   Applications which use this media types

   Various SRGS implementations use this media type.

3.5  Security Considerations

   Several instructions in SRGS may cause arbitrary URIs to be
   dereferenced.  In this case, the security issues of [RFC2396],
   section 7, should be considered.

   In addition, because of the extensibility features of SRGS, it is
   possible that the registered media types may describe content that
   has security implications beyond those described here.  However, if
   the processor follows only the normative semantics of the
   specifications, 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.

3.6  Additional Information

3.6.1  Magic numbers

   The ABNF self-identifying header must be present in any legal

Froumentin              Expires September 2, 2005               [Page 7]

Internet-Draft    W3C Speech Interface Framework Media Types  March 2005

   stand-alone ABNF Form grammar document.  The first character of an
   ABNF document must be the "#" symbol (x23) unless preceded by an
   optional XML 1.0 byte order mark [XML ?4.3.3].  The ABNF byte order
   mark follows the XML definition and requirements.  For example,
   documents encoded in UTF-16 must begin with the byte order mark.  The
   optional byte order mark and required "#" symbol must be followed
   immediately by the exact string "ABNF" (x41 x42 x4d x46) or the
   appropriate equivalent for the document's encoding (e.g.  for UTF-16
   little-endian: x23 x00 x41 x00 x42 x00 x4d x00 x46 x00).  If the byte
   order mark is absent on a grammar encoded in UTF-16 then the grammar
   processor should perform auto-detection of character encoding in a
   manner analogous to auto-detection of character encoding in XML [XML
   ?F].  Next follows a single space character (x20) and the required
   version number which is "1.0" for this specification (x31 x2e x30).

3.6.2  File extensions

   .gram

3.6.3  Macintosh File Type Code

   "TEXT"

3.6.4  Person & email address to contact for further information

   World Wide Web Consortium <[email-masked]>

3.6.5  Intended usage

   COMMON

3.6.6  Change Controller

   The SRGS specification is a work product of the World Wide Web
   Consortium's Voice Browser Working Group.  The W3C has change control
   over the SRGS specification.

4.  References

   [CCXML]    Auburn, RJ., Ed., "Voice Browser Call Control: CCXML
              Version 1.0, W3C Working Draft", January 2005,
              <http://www.w3.org/TR/2005/WD-ccxml-20050111/>.

   [PLS]      Baggia, P., Ed., "Pronunciation Lexicon Specification
              (PLS) Version 1.0, W3C Working Draft", February 2005,
              <http://www.w3.org/TR/2005/WD-pronunciation-lexicon-200502
              14/>.

Froumentin              Expires September 2, 2005               [Page 8]

Internet-Draft    W3C Speech Interface Framework Media Types  March 2005

   [RFC2396]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
              Resource Identifiers (URI): Generic Syntax.  IETF RFC
              2396", August 1998, <http://www.ietf.org/rfc/rfc2396.txt>.

   [RFC3023]  Murata, M., St.Laurent, S. and D. Kohn, "XML Media Types",
              January 2001, <http://www.ietf.org/rfc/rfc3023.txt>.

   [SRGS]     Hunt, A., Ed. and S. McGlashan, Ed., "Speech Recognition
              Grammar Specification Version 1.0, W3C Recommendation",
              March 2004,
              <http://www.w3.org/TR/2004/REC-speech-grammar-20040316/>.

   [SSML]     Burnett, D., Ed., Walker, M., Ed. and A. Hunt, Ed.,
              "Speech Synthesis Markup Language (SSML) Version 1.0, W3C
              Recomendation", September 2004,
              <http://www.w3.org/TR/2004/REC-speech-synthesis-20040907/>
              .

   [VoiceXML2.0]
              McGlashan, S., Ed., "Voice Extensible Markup Language
              (VoiceXML) Version 2.0, W3C Recommendation", March 2004,
              <http://www.w3.org/TR/2004/REC-voicexml20-20040316/>.

   [VoiceXML2.1]
              Oshry, M., Ed., "Voice Extensible Markup Language
              (VoiceXML) Version 2.1, W3C Working Draft", July 2004,
              <http://www.w3.org/TR/2004/WD-voicexml21-20040728/>.

Author's Address

   Max Froumentin
   World Wide Web Consortium

Froumentin              Expires September 2, 2005               [Page 9]

Internet-Draft    W3C Speech Interface Framework Media Types  March 2005

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Froumentin              Expires September 2, 2005              [Page 10]

From: mf at w3.org (Max Froumentin)
Date: Tue Jan  3 16:22:57 2006
Subject: please review draft-froumentin-voice-mediatypes-00
Message-ID: <[email-masked]>

draft-froumentin-voice-mediatypes-00 contains the registration of 
the 6 media types of the W3C Speech Interface Framework
(including the following specifications: SSML, SRGS, CCXML, PLS and VoiceXML)

Draft available at
http://www.ietf.org/internet-drafts/draft-froumentin-voice-mediatypes-00.txt
and copied below.

Max Froumentin, W3C

Network Working Group                                      M. Froumentin
Internet-Draft                                                       W3C
Expires: September 2, 2005                                    March 2005

            The W3C Speech Interface Framework Media Types:
  application/voicexml+xml,  application/ssml+xml,  application/srgs,
  application/srgs+xml, application/ccxml+xml and application/pls+xml
                  draft-froumentin-voice-mediatypes-00

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 2, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document defines the media type for the languages of the W3C
   Speech Interface Framework: VoiceXML, SSML, SRGS, CCXML and PLS.

Froumentin              Expires September 2, 2005               [Page 1]

Internet-Draft    W3C Speech Interface Framework Media Types  March 2005

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Registration of application/voicexml+xml,
       application/ssml+xml, application/srgs+xml,
       application/ccxml+xml and application/pls+xml  . . . . . . . .  4
     2.1   Encoding considerations  . . . . . . . . . . . . . . . . .  4
     2.2   Interoperability considerations  . . . . . . . . . . . . .  4
     2.3   Published specifications . . . . . . . . . . . . . . . . .  4
     2.4   Applications which use these media types . . . . . . . . .  4
     2.5   Security Considerations  . . . . . . . . . . . . . . . . .  4
     2.6   Additional Information . . . . . . . . . . . . . . . . . .  5
       2.6.1   Magic numbers  . . . . . . . . . . . . . . . . . . . .  5
       2.6.2   File extensions  . . . . . . . . . . . . . . . . . . .  5
       2.6.3   Fragment identifiers . . . . . . . . . . . . . . . . .  5
       2.6.4   Macintosh File Type Code . . . . . . . . . . . . . . .  5
       2.6.5   Person & email address to contact for further
               information  . . . . . . . . . . . . . . . . . . . . .  5
       2.6.6   Intended usage . . . . . . . . . . . . . . . . . . . .  5
       2.6.7   Change Controller  . . . . . . . . . . . . . . . . . .  5
   3.  Registration of application/srgs . . . . . . . . . . . . . . .  7
     3.1   Encoding considerations  . . . . . . . . . . . . . . . . .  7
     3.2   Interoperability considerations  . . . . . . . . . . . . .  7
     3.3   Published specifications . . . . . . . . . . . . . . . . .  7
     3.4   Applications which use this media types  . . . . . . . . .  7
     3.5   Security Considerations  . . . . . . . . . . . . . . . . .  7
     3.6   Additional Information . . . . . . . . . . . . . . . . . .  7
       3.6.1   Magic numbers  . . . . . . . . . . . . . . . . . . . .  7
       3.6.2   File extensions  . . . . . . . . . . . . . . . . . . .  8
       3.6.3   Macintosh File Type Code . . . . . . . . . . . . . . .  8
       3.6.4   Person & email address to contact for further
               information  . . . . . . . . . . . . . . . . . . . . .  8
       3.6.5   Intended usage . . . . . . . . . . . . . . . . . . . .  8
       3.6.6   Change Controller  . . . . . . . . . . . . . . . . . .  8
   4.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  9
       Intellectual Property and Copyright Statements . . . . . . . . 10

Froumentin              Expires September 2, 2005               [Page 2]

Internet-Draft    W3C Speech Interface Framework Media Types  March 2005

1.  Introduction

   This specification defines the media types of the VoiceXML, SSML,
   SRGS, CCXML and PLS, the specifications of the W3C Speech Interface
   Platform

   VoiceXML is an XML language designed for creating audio dialogs that
   feature synthesized speech, digitized audio, recognition of spoken
   and DTMF key input, recording of spoken input, telephony, and mixed
   initiative conversations.  The associated media type defined in this
   document is "application/voicexml+xml".

   The Speech Synthesis Markup Language Specification (SSML) defines an
   XML-based markup language for assisting the generation of synthetic
   speech in Web and other applications.  The essential role of SSML is
   to provide authors of synthesizable content a standard way to control
   aspects of speech such as pronunciation, volume, pitch, rate, etc.
   across different synthesis-capable platforms.  The asociated media
   type defined in this document is "application/ssml+xml".

   The Speech Recognition Grammar Specification (SRGS) defines syntax
   for representing grammars for use in speech recognition so that
   developers can specify the words and patterns of words to be listened
   for by a speech recognizer.  The syntax of the grammar format exists
   in two forms, an Augmented BNF Form and an XML Form.  The respective
   media types defined in this document are "application/srgs" and
   "application/srgs+xml".

   The Call Control eXtensible Markup Language (CCXML) is an XML
   language designed to provide telephony call control support for
   dialog systems, such as VoiceXML.  The associated media type defined
   in this document is "application/ccxml+xml".

   The Pronunciation Lexicon Specification (PLS) defines an XML syntax
   for specifying pronunciation lexicons to be used by speech
   recognition and speech synthesis engines in voice browser
   applications.  The associated media type defined in this document is
   "application/pls+xml".

Froumentin              Expires September 2, 2005               [Page 3]

Internet-Draft    W3C Speech Interface Framework Media Types  March 2005

2.  Registration of application/voicexml+xml, application/ssml+xml,
   application/srgs+xml, application/ccxml+xml and application/pls+xml

      MIME media type name: application
      MIME subtype names: voicexml+xml, ssml+xml, srgs+xml, ccxml+xml,
      pls+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 RFC 3023 [RFC3023].

2.1  Encoding considerations

   Identical to those of "application/xml" as described in RFC 3023
   [RFC3023], section 3.2

2.2  Interoperability considerations

   There are no known interoperability issues.

2.3  Published specifications

      Voice Extensible Markup Language 2.0 [VoiceXML2.0]
      Voice Extensible Markup Language 2.1 [VoiceXML2.1]
      Speech Synthesis Markup Language (SSML) Version 1.0 [SSML]
      Speech Recognition Grammar Specification Version 1.0 [SRGS]
      Voice Browser Call Control: CCXML Version 1.0 [CCXML]
      Pronunciation Lexicon Specification (PLS) Version 1.0 [PLS]

2.4   Applications which use these media types

   Various W3C Speech Interface Platform implementations use these media
   types

2.5  Security Considerations

   Several instructions in the cited specifications may cause arbitrary
   URIs to be dereferenced.  In this case, the security issues of
   [RFC2396], section 7, should be considered.

   In addition, because of the extensibility features of those
   specifications, it is possible that the registered media types may
   describe content that has security implications beyond those
   described here.  However, if the processor follows only the normative
   semantics of the specifications, 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

Froumentin              Expires September 2, 2005               [Page 4]

Internet-Draft    W3C Speech Interface Framework Media Types  March 2005

   dispatched to other processors, would security issues potentially
   arise.  And in that case, they would fall outside the domain of this
   registration document.

2.6  Additional Information

2.6.1  Magic numbers

   Although no byte sequences can be counted on to always be present,
   XML MIME entities in ASCII-compatible charsets (including UTF-8)
   often begin with hexadecimal 3C 3F 78 6D 6C ("<?xml"), and those in
   UTF-16 often begin with hexadecimal FE FF 00 3C 00 3F 00 78 00 6D 00
   6C or FF FE 3C 00 3F 00 78 00 6D 00 6C 00 (the Byte Order Mark (BOM)
   followed by "<?xml").  For more information, see Appendix F of [XML].

2.6.2  File extensions

   VoiceXML files: .vxml

   SSML files: .ssml

   SRGS files (XML syntax): .grxml

   CCXML files: .ccxml

   PLS files: .pls

2.6.3  Fragment identifiers

   Identical to that of "application/xml" as described in RFC 3023
   [RFC3023], section 5.

2.6.4  Macintosh File Type Code

   "TEXT"

2.6.5  Person & email address to contact for further information

   World Wide Web Consortium <[email-masked]>

2.6.6  Intended usage

   COMMON

2.6.7  Change Controller

   The Speech Interface Framework specifications set is a work product
   of the World Wide Web Consortium's Voice Browser Working Group.  The

Froumentin              Expires September 2, 2005               [Page 5]

Internet-Draft    W3C Speech Interface Framework Media Types  March 2005

   W3C has change control over these specifications.

Froumentin              Expires September 2, 2005               [Page 6]

Internet-Draft    W3C Speech Interface Framework Media Types  March 2005

3.  Registration of application/srgs

      MIME media type name: application
      MIME subtype names: srgs
      Required parameters: none
      Optional parameters: none

3.1  Encoding considerations

   The ABNF Form of SRGS follows the character encoding handling defined
   for XML: an ABNF grammar processor must accept both the UTF-8 and
   UTF-16 encodings of ISO/IEC 10646 and may support other character
   encodings.

3.2  Interoperability considerations

   There are no known interoperability issues.

3.3  Published specifications

      Speech Recognition Grammar Specification Version 1.0 [SRGS]

3.4   Applications which use this media types

   Various SRGS implementations use this media type.

3.5  Security Considerations

   Several instructions in SRGS may cause arbitrary URIs to be
   dereferenced.  In this case, the security issues of [RFC2396],
   section 7, should be considered.

   In addition, because of the extensibility features of SRGS, it is
   possible that the registered media types may describe content that
   has security implications beyond those described here.  However, if
   the processor follows only the normative semantics of the
   specifications, 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.

3.6  Additional Information

3.6.1  Magic numbers

   The ABNF self-identifying header must be present in any legal

Froumentin              Expires September 2, 2005               [Page 7]

Internet-Draft    W3C Speech Interface Framework Media Types  March 2005

   stand-alone ABNF Form grammar document.  The first character of an
   ABNF document must be the "#" symbol (x23) unless preceded by an
   optional XML 1.0 byte order mark [XML ?4.3.3].  The ABNF byte order
   mark follows the XML definition and requirements.  For example,
   documents encoded in UTF-16 must begin with the byte order mark.  The
   optional byte order mark and required "#" symbol must be followed
   immediately by the exact string "ABNF" (x41 x42 x4d x46) or the
   appropriate equivalent for the document's encoding (e.g.  for UTF-16
   little-endian: x23 x00 x41 x00 x42 x00 x4d x00 x46 x00).  If the byte
   order mark is absent on a grammar encoded in UTF-16 then the grammar
   processor should perform auto-detection of character encoding in a
   manner analogous to auto-detection of character encoding in XML [XML
   ?F].  Next follows a single space character (x20) and the required
   version number which is "1.0" for this specification (x31 x2e x30).

3.6.2  File extensions

   .gram

3.6.3  Macintosh File Type Code

   "TEXT"

3.6.4  Person & email address to contact for further information

   World Wide Web Consortium <[email-masked]>

3.6.5  Intended usage

   COMMON

3.6.6  Change Controller

   The SRGS specification is a work product of the World Wide Web
   Consortium's Voice Browser Working Group.  The W3C has change control
   over the SRGS specification.

4.  References

   [CCXML]    Auburn, RJ., Ed., "Voice Browser Call Control: CCXML
              Version 1.0, W3C Working Draft", January 2005,
              <http://www.w3.org/TR/2005/WD-ccxml-20050111/>.

   [PLS]      Baggia, P., Ed., "Pronunciation Lexicon Specification
              (PLS) Version 1.0, W3C Working Draft", February 2005,
              <http://www.w3.org/TR/2005/WD-pronunciation-lexicon-200502
              14/>.

Froumentin              Expires September 2, 2005               [Page 8]

Internet-Draft    W3C Speech Interface Framework Media Types  March 2005

   [RFC2396]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
              Resource Identifiers (URI): Generic Syntax.  IETF RFC
              2396", August 1998, <http://www.ietf.org/rfc/rfc2396.txt>.

   [RFC3023]  Murata, M., St.Laurent, S. and D. Kohn, "XML Media Types",
              January 2001, <http://www.ietf.org/rfc/rfc3023.txt>.

   [SRGS]     Hunt, A., Ed. and S. McGlashan, Ed., "Speech Recognition
              Grammar Specification Version 1.0, W3C Recommendation",
              March 2004,
              <http://www.w3.org/TR/2004/REC-speech-grammar-20040316/>.

   [SSML]     Burnett, D., Ed., Walker, M., Ed. and A. Hunt, Ed.,
              "Speech Synthesis Markup Language (SSML) Version 1.0, W3C
              Recomendation", September 2004,
              <http://www.w3.org/TR/2004/REC-speech-synthesis-20040907/>
              .

   [VoiceXML2.0]
              McGlashan, S., Ed., "Voice Extensible Markup Language
              (VoiceXML) Version 2.0, W3C Recommendation", March 2004,
              <http://www.w3.org/TR/2004/REC-voicexml20-20040316/>.

   [VoiceXML2.1]
              Oshry, M., Ed., "Voice Extensible Markup Language
              (VoiceXML) Version 2.1, W3C Working Draft", July 2004,
              <http://www.w3.org/TR/2004/WD-voicexml21-20040728/>.

Author's Address

   Max Froumentin
   World Wide Web Consortium

Froumentin              Expires September 2, 2005               [Page 9]

Internet-Draft    W3C Speech Interface Framework Media Types  March 2005

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Froumentin              Expires September 2, 2005              [Page 10]

From: YakovS at solidmatrix.com (Yakov Shafranovich)
Date: Sun Apr  3 08:18:45 2005
Subject: Media Type "text/csv": new draft (-02) and Last Call
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

I added this language to the -04 draft. Regarding the issue of the 
header, I added an optional "header" parameter to the MIME type that can 
be used to indicate the presence or absence of the header line.

Yakov

[email-masked] wrote:
> Yakov,
> 
> That draft wording sounds excellent.
> 
> Now, if you were to ALSO mandate the presence of the header record, that 
> would mitigate my concern that computer applications should be able to 
> exchange CSV files without worrying about same field order (simply 
> because the header conveys the field names, rather than needing an 
> out-of-band, bilateral agreement).  And, of course, presence of a header 
> record lets a computer application determine immediately whether the 
> supplied fields are likely to be what it expects.   All good aids for 
> careful validation.
> 
> Thank-you,
> Clyde
> 
> -----Original Message-----
> From: Yakov Shafranovich [mailto:[email-masked]]
> Sent: Wednesday, March 30, 2005 8:08 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: Media Type "text/csv": new draft (-02) and Last Call
> 
> 
> [email-masked] wrote:
>  >
>  > But the same cannot be said of automated computer-based applications,
>  > where maintaining a strict count of generated and expected
>  > Comma-Separated-Values per record is not only easy, but also allows for
>  > an extra level of data validation: namely that a received record is
>  > corrupt if it has too few or too many fields.  This is where
>  > standardisation in the format of the CSV records becomes appropriate
>  > material for an RFC.
>  >
> 
> The draft as it is written now (-03) does not mandate that the same
> number of fields need to appear on each line, mainly due to the fact
> that the draft is focusing on the MIME type registration. Would the
> following change to section 2, subsection 4 be sufficient to address
> your concerns:
> 
> "Within the header and each record there may be one or more fields,
> separated by commas. Each line should contain the same number of fields
> throughout the file. The last field in the record may not be followed by
> a comma. For example:"
> 
> Yakov
> 

From: YakovS at solidmatrix.com (Yakov Shafranovich)
Date: Tue Jan  3 16:22:57 2006
Subject: Media Type "text/csv": new draft (-02) and Last Call
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

I added this language to the -04 draft. Regarding the issue of the 
header, I added an optional "header" parameter to the MIME type that can 
be used to indicate the presence or absence of the header line.

Yakov

[email-masked] wrote:
> Yakov,
> 
> That draft wording sounds excellent.
> 
> Now, if you were to ALSO mandate the presence of the header record, that 
> would mitigate my concern that computer applications should be able to 
> exchange CSV files without worrying about same field order (simply 
> because the header conveys the field names, rather than needing an 
> out-of-band, bilateral agreement).  And, of course, presence of a header 
> record lets a computer application determine immediately whether the 
> supplied fields are likely to be what it expects.   All good aids for 
> careful validation.
> 
> Thank-you,
> Clyde
> 
> -----Original Message-----
> From: Yakov Shafranovich [mailto:[email-masked]]
> Sent: Wednesday, March 30, 2005 8:08 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: Media Type "text/csv": new draft (-02) and Last Call
> 
> 
> [email-masked] wrote:
>  >
>  > But the same cannot be said of automated computer-based applications,
>  > where maintaining a strict count of generated and expected
>  > Comma-Separated-Values per record is not only easy, but also allows for
>  > an extra level of data validation: namely that a received record is
>  > corrupt if it has too few or too many fields.  This is where
>  > standardisation in the format of the CSV records becomes appropriate
>  > material for an RFC.
>  >
> 
> The draft as it is written now (-03) does not mandate that the same
> number of fields need to appear on each line, mainly due to the fact
> that the draft is focusing on the MIME type registration. Would the
> following change to section 2, subsection 4 be sufficient to address
> your concerns:
> 
> "Within the header and each record there may be one or more fields,
> separated by commas. Each line should contain the same number of fields
> throughout the file. The last field in the record may not be followed by
> a comma. For example:"
> 
> Yakov
> 

From: YakovS at solidmatrix.com (Yakov Shafranovich)
Date: Sun Apr  3 08:14:09 2005
Subject: Type 'text/csv', draft-04
Message-ID: <[email-masked]>

I posted a new version (-04) correcting the ABNF grammar in response to 
IESG comments, adding a few clarifications and adding a new optional 
"header" parameter to indicate the absence or presence of a header line. 
Copies of the draft can be found below and the draft should post to the 
IETF ID repository sometime Monday:

http://www.shaftek.org/publications/drafts/mime-csv/draft-shafranovich-mime-csv-04.html
http://www.shaftek.org/publications/drafts/mime-csv/draft-shafranovich-mime-csv-04.txt

HTML and text diff of changes:

http://www.shaftek.org/publications/drafts/mime-csv/rfcdiff-03-to-04.html
http://www.shaftek.org/publications/drafts/mime-csv/diff-03-to-04.txt

Yakov