- Ietf-types - alvestrand.no

RE: [AVT] Re: Request to review media type in AVT working group lastcall: draft-ietf-avt-rtp-3gpp-timed-text.txt
by Jose Rey 02 Jun '05

02 Jun '05

Ned, > > > Hi Ned, > > > The word smithing looks fine and is say that we go with > your proposal. > > > Ned Freed wrote: > > > > > > At one point I suggest it might be appropriate to map the > U bit to a > > > charset parameter. Does this make any sense to do? > > > > > > I would say no. If there was a possibility to move beyond UTF-8 and > > UTF-16 I would probably agree. However as these are the > only charsets > > allowed and both are mandatory I don't see that it would > provide any > > benefit at all. > > Then why do you need the U bit? > > Let me be clear here. I have no problem with not defining the > parameter, but I don't understand why the number of charsets > involved forms a criteria for whether or not it is needed. > I'm just trying to understand a bit more about the nature of > the underlying transport, I guess. The initial motivation was to enable text fragments to be decoded even if the complete text sample was not received (selfcontained). Instead of repeating the 16 bit BOM in every packet we use a 1 bit indication. That's all. José

1 0

RE: [AVT] Re: Request to review media type in AVT working group last call: draft-ietf-avt-rtp-3gpp-timed-text.txt
by Ned Freed 02 Jun '05

02 Jun '05

> Hi Ned, > Thanks for the comments and enhancements. Agreed stuff has been cut... > > At one point I suggest it might be appropriate to map the U > > bit to a charset parameter. Does this make any sense to do? > Sorry, I am not sure what you mean with that. DO you mean to change the name of the field or the field in the payload format? My understanding is that it is common practice when defining AVT media types to say "this media type has associated with it parameter foo, parameter foo is mapped in the following way to such and such fields in SDP". My question was whether or not it made sense to map the U bit (which states whether the underlying text in the media type is utf-8 or utf-16) to a corresponding charset parameter with values of utf-8 and utf-16 (or whatever utf-16 endian variant is appropriate), and if not, why not. Ned

1 0

RE: [AVT] Re: Request to review media type in AVT working group last call: draft-ietf-avt-rtp-3gpp-timed-text.txt
by Jose Rey 02 Jun '05

02 Jun '05

Hi Ned, Thanks for the comments and enhancements. Agreed stuff has been cut... > At one point I suggest it might be appropriate to map the U > bit to a charset parameter. Does this make any sense to do? Sorry, I am not sure what you mean with that. DO you mean to change the name of the field or the field in the payload format? Comments? José > > Ned > > _______________________________________________ > Audio/Video Transport Working Group > avt(a)ietf.org > https://www1.ietf.org/mailman/listinfo/avt > >

1 0

Request to review media type in AVT working group last call: draft-ietf-avt-rtp-3gpp-timed-text.txt
by Magnus Westerlund 02 Jun '05

02 Jun '05

The AVT chairs would like to request a review of the RTP only media type: text/3gpp-tt This definition is currently in AVT WG last call, so please send any comment prior to the 2nd of June. This type is defined in section 8 of http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-3gpp-timed-text-14.t… Thanks Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund(a)ericsson.com

7 27

Re: I-D ACTION:draft-lilly-text-troff-04.txt
by Tony Hansen 27 May '05

27 May '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Can the examples be changed such that at least one of them (if not both) uses prose text in the process= parameter? I'd like it to made be even more clear that these are not executable statements. For example, instead of process="pic -n | troff -ms" how about process="needs pic -n and troff -ms" ? Tony Hansen tony(a)att.com Internet-Drafts(a)ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Media subtype registration for media type text/troff > Author(s) : B. Lilly > Filename : draft-lilly-text-troff-04.txt,.ps,.pdf > Pages : 15 > Date : 2005-5-27 > > A text media subtype for tagging content consisting of juxtaposed > text and formatting directives as used by the troff series of > programs and for conveying information about the intended processing > steps necessary to produce formatted output is described. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCl4/sxsSylYhzrRYRAuEhAJ43RL98Yjk6fyZTN17VqQ14MNXWFwCfavvG 9Bg+qFSQeHDP5XeCUnc8zH0= =VHIL -----END PGP SIGNATURE-----

3 3

Registration of mime types app/vnd.de.bund.bsi.chiasmus{, -encrypted}
by Marc Mutz 16 May '05

16 May '05

Hi, as per relevant RFCs, we are submitting the draft registrations for application/vnd.de.bund.bsi.chiasmus and application/vnd.de.bund.bsi.chiasmus-encrypted for the two-week review period before proceeding with registration at IANA. Marc -- Marc Mutz -- marc(a)klaralvdalens-datakonsult.se, mutz(a)kde.org phone: +49 521 521 45 45; mobile: +49 177 32 94 700 Klarälvdalens Datakonsult AB, Platform-independent software solutions

1 0

Re: text changes to text/troff draft wording
by Keith Moore 11 May '05

11 May '05

> > 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]). > > Does that adequately address concerns raised during Last Call? I would change "Implementations" to "Receiving Implementations". I would change SHOULD NOT to MUST NOT because I cannot identify any conditions where it is reasonable for a receiving implementation to execute the content. I would add "Sending Implementations MUST NOT use the parameter value to encode executable content." to discourage Receiving Implementations from attempting to interpret that parameter as executable content. Keith

4 8

Re: regarding your comments on proposed media type text/troff' to Informational RFC
by Keith Moore 02 May '05

02 May '05

[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:moore@cs.utk.edu] >> Sent: Tuesday, April 12, 2005 4:14 PM >> To: iesg(a)ietf.org >> Cc: moore(a)cs.utk.edu >> 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

4 21

MIME media types in RFC 4047
by Steve Allen 30 Apr '05

30 Apr '05

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 sla(a)ucolick.org 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

2 1

Request for comments regarding draft-mccobb-xplusv-media-type-01
by Gerald McCobb 21 Apr '05

21 Apr '05

This is a request for comments regarding the internet draft draft-mccobb-xplusv-media-type-01 for media type "application/xhtml+voice+xml". This media type is for XHTML+Voice documents. The XHTML+Voice specification is located at http://www.voicexml.org/specs/multimodal/x+v/12/ . Network Working Group G. McCobb Internet-Draft IBM Corporation Expires: May 15, 2005 Nov. 15, 2004 XHTML+Voice - application/xhtml+voice+xml draft-mccobb-xplusv-media-type-01 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 [REQ]. Mccobb Expires May 15, 2005 [Page 1] Internet-Draft XHTML+Voice - application/xhtml+voice+xml Nov. 15, 2004 2. Introduction XHTML+VOice is a member of the XHTML family of document types, as specified by XHTML Modularization. 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 documents. This media type registration is not intended for email usage. 3. IANA Registration To: ietf-types(a)iana.org 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: version: refers to the XHTML+Voice language version in the document. Acceptable values are 1.0, 1.1, and 1.2 (default). charset: has the same meaning as the text/html media type. See section 2 of [RFC 2854]. Encoding considerations: 7bit. See section 4 of [RFC 2854]. 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 Mccobb Expires May 15, 2005 [Page 2] Internet-Draft XHTML+Voice - application/xhtml+voice+xml Nov. 15, 2004 documents, and scripting languages and other dynamic interactive capabilities. See section 7 of [RFC 2854]. 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. See section 2 of [RFC 2854]. Additional information: Magic number(s): There is no single string that is always present. File extension(s): html, htm, mxml, xvml Macintosh File Type Code(s): TEXT Person & email address to contact for further information: Gerald M. McCobb mccobb(a)us.ibm.com Intended usage: COMMON Author/Change controller: Gerald McCobb Further information: 4. Fragment Identifiers See section 3 of [RFC 2854]. 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 Mccobb Expires May 15, 2005 [Page 3] Internet-Draft XHTML+Voice - application/xhtml+voice+xml Nov. 15, 2004 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 4. 7. References [REQ] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [DOM2EV] "Document Object Model Level 2 Events Specification," Tom Pixley, 2000. W3C Recommendation, http://www.w3.org/TR/DOM-Level-2-Events/. [HTML401] Raggett, D., et al., "HTML 4.01 Specification", W3C Recommendation, December 1999. Available at <http://www.w3.org/TR/html401>. [MIME4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996. [RFC 2854] RFC 2854: The 'text/html' Media Type, Connolly and Masinter, June 2000, http://www.ietf.org/rfc/rfc2854.txt. [XHTMLMOD] "Modularization of XHTML," 10 April, 2001, Murray Altheim, Frank Boumphrey, Sam Dooley, et al, W3C Recommendation, http://www.w3.org/TR/xhtml-modularization/ [XHTML1] "XHTML 1.0: The Extensible HyperText Markup Language: A Reformulation of HTML 4 in XML 1.0", W3C Recommendation, January 2000. Available at <http://www.w3.org/TR/xhtml1>. [XHTML11] "XHTML 1.1 - Module-based XHTML," 31 May 2001, Murray Altheim, Shane McCarron, W3C Recommendation, http://www.w3.org/TR/xhtml11/. [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/. Mccobb Expires May 15, 2005 [Page 4] Internet-Draft XHTML+Voice - application/xhtml+voice+xml Nov. 15, 2004 [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: mccobb(a)us.ibm.com 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 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 Mccobb Expires May 15, 2005 [Page 5] Internet-Draft XHTML+Voice - application/xhtml+voice+xml Nov. 15, 2004 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- ipr(a)ietf.org. 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

2 3