regarding your comments on proposed media type text/troff' to Informational RFC

[blilly at erols.com (Bruce Lilly)]

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 [e-mail]  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: <[e-mail]>
References: <[e-mail]>
	<[e-mail]> <[e-mail]>
Message-ID: <[e-mail]>

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 [e-mail]  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: <[e-mail]>
References: <[e-mail]>
	<[e-mail]> <[e-mail]>
Message-ID: <[e-mail]>

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 [e-mail]  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: <[e-mail]>
References: <[e-mail]>
	<[e-mail]> <[e-mail]>
Message-ID: <[e-mail]>

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 [e-mail]  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: <[e-mail]>
Message-ID: <[e-mail]>

In response to your previous comments (thanks) I submitted 
draft-mccobb-xplusv-media-type-02.txt to [e-mail].  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: [e-mail]
      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
         [e-mail]

      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: [phone]
   Fax:   [phone]
   EMail: [e-mail]


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-
   [e-mail].

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. # [phone] T/L 975-2109





Bjoern Hoehrmann <[e-mail]>
03/26/2005 06:06 PM
 
        To:     Gerald McCobb/Boca Raton/IBM@IBMUS
        cc:     [e-mail], [e-mail]
        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:[e-mail] ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: [phone] ? 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 [e-mail]  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: <[e-mail]>

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
[e-mail]      Voice: [phone]     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 [e-mail]  Sat Apr 30 17:52:18 2005
From: ned.freed at mrochek.com ([e-mail])
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"
	<[e-mail]>
References: <[e-mail]>
Message-ID: <[e-mail]>

> 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 [e-mail]  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: <[e-mail]>

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