March 2005 - Ietf-types

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

RE: Media Type "text/csv": new draft (-02) and Last Call
by clyde.ingram＠edl.uk.eds.com 03 Apr '05

03 Apr '05

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:research@solidmatrix.com] Sent: Wednesday, March 30, 2005 8:08 PM To: clyde.ingram(a)edl.uk.eds.com Cc: GK-lists(a)ninebynine.org; ietf-types(a)alvestrand.no Subject: Re: Media Type "text/csv": new draft (-02) and Last Call clyde.ingram(a)edl.uk.eds.com 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

2 1

Re: Media Type "text/csv": new draft (-02) and Last Call
by Graham Klyne 31 Mar '05

31 Mar '05

At 14:08 30/03/05 -0500, Yakov Shafranovich wrote: >clyde.ingram(a)edl.uk.eds.com 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:" I think this change would *decrease* the utility of the proposed MIME type registration, which I see as being to document existing practice so that new applications can interoperate with it. I think the benefits of interworking with existing practice greatly outweigh the purported advantage of (weak) integrity checking. In this case, I really think that less [specification] is more. #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

RE: Media Type "text/csv": new draft (-02) and Last Call
by clyde.ingram＠edl.uk.eds.com 30 Mar '05

30 Mar '05

Graham & Yakov, Where a Comma-Separated-Value format is used by peer computer applications attempting to communicate with each other in an open fashion, it is very simple for them to produce a fixed number of Comma-Separated-Values. It sounds like your production of a variable number of Comma-Separated-Values is an artefact of how you are manually driving one proprietary spreadsheet program from the keyboard/mouse. If such manually generated output is to be read by a similarly manually driven mechanism, then it may be acceptable to have variable numbers of Comma-Separated-Values per record. Standardisation in numbers of fieldds is then unnecessary, so an RFC need not cater for the uncontrolled nature of manually handled data. 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. Regards, Clyde Ingram -----Original Message----- From: Graham Klyne [mailto:GK-lists@ninebynine.org] Sent: Tuesday, March 29, 2005 12:21 PM To: clyde.ingram(a)edl.uk.eds.com; YakovS(a)solidmatrix.com Cc: ietf-types(a)alvestrand.no Subject: RE: Media Type "text/csv": new draft (-02) and Last Call At 15:19 23/03/05 +0000, clyde.ingram(a)edl.uk.eds.com wrote: >Please clarify whether the trailing commas that your Excel export >generates are there to mark the end of the last field, or to mark the >start of a last field which currently has no value. I'm not sure how to tell the difference in an Excel spreadsheet. In the case where this arose for me, I had created a speadsheet with varying numbers of values in different rows, and many of the rows were output by Excel with *multiple* trailing commas. Some rows were generated without any trailimng commas. My point would be that if this happens with reasonable data then is must be permitted. Whether it's interpreted as a field terminator as start of field with no value is, I think, moot. #g -- >Graham, > >-----Original Message----- >From: Graham Klyne >[<mailto:GK-lists@ninebynine.org>mailto:GK-lists@ninebynine.org] >Sent: Wednesday, March 23, 2005 9:55 AM >To: Yakov Shafranovich; clyde.ingram(a)edl.uk.eds.com >Cc: ietf-types(a)alvestrand.no >Subject: Re: Media Type "text/csv": new draft (-02) and Last Call > >At 01:14 23/03/05 -0500, Yakov Shafranovich wrote: > > >Clyde, > > > >Thanks for pointing this out. I personally think that instead of making > >the header record mandatory which is something that most CSV applications > >do not have, I would rather take the comma out of the end of the record > >and have the last field end with a CRLF instead of an optional COMMA. Do > >you think that is a plausible solution? > >No. Some of the Excel data I process has trailing commas. This must be >allowed. > >I also don't think it's necessary to say anything (other than maybe as a >comment) about any special status for the first line: such use is >accommodated quite reasonably within the basic CSV format. > >For example, having such a line when exporting Excel as CSV depends >entirely upon how the user constructs the original spreadsheet. Column >headings are common, but not mandatory. In some cases, there may be a more >complex heading structure -- this is an application issue, not a dataset >format issue, and as such does not belong in the dataset format >specification. > >#g >-- >------------ > >Please clarify whether the trailing commas that your Excel export >generates are there to mark the end of the last field, or to mark the >start of a last field which currently has no value. > >To take a concrete example, I would expect a CSV of sibling relationships >in a mythical family to look like this, assuming the siblings are one >brother (Bart) and 2 sisters (Lisa & Maggie): > > child,sisters,brothers<CR-LF> > Bart,Lisa & Maggie,<CR-LF> > Lisa,Maggie,Bart<CR-LF> > Maggie,Lisa,Bart<CR-LF> > >where the trailing comma for the record of child=Bart signifies that the >"brothers" field is null, so that Bart has no brothers. In my view this >is a logical conclusion, and in fact stripping that one trailing comma >would be an error, as that record would only have 2 fields, not 3. > >Would you, however, expect the CSV file to use comma as a >field-terminator, rather than a field-separator, as follows?: > > child,sisters,brothers,<CR-LF> > Bart,Lisa & Maggie,,<CR-LF> > Lisa,Maggie,Bart,<CR-LF> > Maggie,Lisa,Bart,<CR-LF> > >Note that parsers that split data records on unprotected comma would >detect one field too many in this latter case. > >In a Comma SEPARATED Value file format, can you configure Excel to use >comma as a SEPARATOR between values, rather than a TERMINATOR (at the end >of values)? > > >Regarding your remarks on the header record being "an application issue, >not a dataset format issue, and as such does not belong in the dataset >format specification": XML, ASN.1, and other (application-independent) >data interchange formats, explicitly tag individual fields so that their >type is unambiguously defined within a context. In contrast, CSV conveys >no tags per field in a data record. Hence, to help with >application-independent data interchange, the CSV format should convey >field titles in a header record. > >Here is an example of lack of application-independence: if my application >sends yours this CSV file: > > ,Bart,Lisa & Maggie<CR-LF> > Bart,Lisa,Maggie<CR-LF> > Bart,Maggie,Lisa<CR-LF> > >and your application depends on the assumption that the fields are the >sequence: > > child > sisters > brothers > >then your application will mis-interpret the data. >But if my application precedes this with a header record, like so: > > brothers,child,sisters<CR-LF> > ,Bart,Lisa & Maggie<CR-LF> > Bart,Lisa,Maggie<CR-LF> > Bart,Maggie,Lisa<CR-LF> > >then your application can maintain independence from the change by my >application, because the CSV file conveys the corresponding new field >sequence (the columns "brother" and "child" have swapped). > >Regards, >Clyde ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

2 1

Re: Media Type "text/csv": new draft (-02) and Last Call
by Yakov Shafranovich 30 Mar '05

30 Mar '05

Graham Klyne wrote: > > I feel compelled to ask the question: should this really be a text/csv > type rather than application/csv? Past comments by Ned Freed with > respect to text/html suggest possibly not, but similarity with > text/tab-separated-values suggests maybe yes. I don't personally feel > strongly about this. > Can you point to Ned's message? > Section 2: > > [[ > 6. Field containing line breaks (CRLF) and commas should be enclosed > in double-quotes. For example: > > "aaa","b CRLF > bb","ccc" CRLF > zzz,yyy,xxx > ]] > > Are there any CSV applications that actually quote newlines in values? > (I'm not sure that my own CSV handling code would accept a newline > within a quoted string) > Some of the code I have been working with is happens to do so. I think it depends on which application you are using. For example I just tried it with OpenOffice Calc v1.1.3 and it accepts newlines within fields. > [[ > 7. If double-quotes are used to enclosed fields, then double-quotes > inside fields must be surrounded by double quotes. For example: > > "aaa","b"""bb","ccc" > ]] > > This is NOT how Excel handles quotes, nor my own code. Rather, when a > quoted string contains a double-quote character, the double quote is > doubled up. Thus the example would be: > "aaa","b""bb","ccc" > I just double checked with the applications that I am using and they tend to work the way you describe. I will adjust the draft. > Section 7.1: > [[ > [3] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, > September 1981. > ]] > > I think this should be an informative reference, not normative. > Thanks for catching that. Yakov

3 2

RE: Media Type "text/csv": new draft (-02) and Last Call
by Graham Klyne 29 Mar '05

29 Mar '05

At 15:19 23/03/05 +0000, clyde.ingram(a)edl.uk.eds.com wrote: >Please clarify whether the trailing commas that your Excel export >generates are there to mark the end of the last field, or to mark the >start of a last field which currently has no value. I'm not sure how to tell the difference in an Excel spreadsheet. In the case where this arose for me, I had created a speadsheet with varying numbers of values in different rows, and many of the rows were output by Excel with *multiple* trailing commas. Some rows were generated without any trailimng commas. My point would be that if this happens with reasonable data then is must be permitted. Whether it's interpreted as a field terminator as start of field with no value is, I think, moot. #g -- >Graham, > >-----Original Message----- >From: Graham Klyne >[<mailto:GK-lists@ninebynine.org>mailto:GK-lists@ninebynine.org] >Sent: Wednesday, March 23, 2005 9:55 AM >To: Yakov Shafranovich; clyde.ingram(a)edl.uk.eds.com >Cc: ietf-types(a)alvestrand.no >Subject: Re: Media Type "text/csv": new draft (-02) and Last Call > >At 01:14 23/03/05 -0500, Yakov Shafranovich wrote: > > >Clyde, > > > >Thanks for pointing this out. I personally think that instead of making > >the header record mandatory which is something that most CSV applications > >do not have, I would rather take the comma out of the end of the record > >and have the last field end with a CRLF instead of an optional COMMA. Do > >you think that is a plausible solution? > >No. Some of the Excel data I process has trailing commas. This must be >allowed. > >I also don't think it's necessary to say anything (other than maybe as a >comment) about any special status for the first line: such use is >accommodated quite reasonably within the basic CSV format. > >For example, having such a line when exporting Excel as CSV depends >entirely upon how the user constructs the original spreadsheet. Column >headings are common, but not mandatory. In some cases, there may be a more >complex heading structure -- this is an application issue, not a dataset >format issue, and as such does not belong in the dataset format >specification. > >#g >-- >------------ > >Please clarify whether the trailing commas that your Excel export >generates are there to mark the end of the last field, or to mark the >start of a last field which currently has no value. > >To take a concrete example, I would expect a CSV of sibling relationships >in a mythical family to look like this, assuming the siblings are one >brother (Bart) and 2 sisters (Lisa & Maggie): > > child,sisters,brothers<CR-LF> > Bart,Lisa & Maggie,<CR-LF> > Lisa,Maggie,Bart<CR-LF> > Maggie,Lisa,Bart<CR-LF> > >where the trailing comma for the record of child=Bart signifies that the >"brothers" field is null, so that Bart has no brothers. In my view this >is a logical conclusion, and in fact stripping that one trailing comma >would be an error, as that record would only have 2 fields, not 3. > >Would you, however, expect the CSV file to use comma as a >field-terminator, rather than a field-separator, as follows?: > > child,sisters,brothers,<CR-LF> > Bart,Lisa & Maggie,,<CR-LF> > Lisa,Maggie,Bart,<CR-LF> > Maggie,Lisa,Bart,<CR-LF> > >Note that parsers that split data records on unprotected comma would >detect one field too many in this latter case. > >In a Comma SEPARATED Value file format, can you configure Excel to use >comma as a SEPARATOR between values, rather than a TERMINATOR (at the end >of values)? > > >Regarding your remarks on the header record being "an application issue, >not a dataset format issue, and as such does not belong in the dataset >format specification": XML, ASN.1, and other (application-independent) >data interchange formats, explicitly tag individual fields so that their >type is unambiguously defined within a context. In contrast, CSV conveys >no tags per field in a data record. Hence, to help with >application-independent data interchange, the CSV format should convey >field titles in a header record. > >Here is an example of lack of application-independence: if my application >sends yours this CSV file: > > ,Bart,Lisa & Maggie<CR-LF> > Bart,Lisa,Maggie<CR-LF> > Bart,Maggie,Lisa<CR-LF> > >and your application depends on the assumption that the fields are the >sequence: > > child > sisters > brothers > >then your application will mis-interpret the data. >But if my application precedes this with a header record, like so: > > brothers,child,sisters<CR-LF> > ,Bart,Lisa & Maggie<CR-LF> > Bart,Lisa,Maggie<CR-LF> > Bart,Maggie,Lisa<CR-LF> > >then your application can maintain independence from the change by my >application, because the CSV file conveys the corresponding new field >sequence (the columns "brother" and "child" have swapped). > >Regards, >Clyde ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

Media Type "text/csv" - trailing nullcols
by Yakov Shafranovich 24 Mar '05

24 Mar '05

Tak, Thanks for your comments. My intent with this draft was to document the current convention and register the MIME type. I would rather stay away from requiring or allowing features explicetly that might not be followed by all implementations. Yakov Yakov Shafranovich wrote: > From: "Tak Tang" <Tak.Tang(a)suht.swest.nhs.uk> > To: <ietf-types(a)alvestrand.no> > Date: Thu, 24 Mar 2005 11:30:43 +0000 > Subj: Media Type "text/csv" - trailing nullcols > > Hello, > > This is my first post, and I've entered the discussion late, so please > excuse me if this has already been discussed . . . > > The draft (03) does not require that each record/line have the same number > of values/commas. > I think it may be benefitial to explicitly allow csv writers to omit > trailing commas if there are no further non-null values. > > eg (all of these lines are valid) > aaa,bbb,ccc,ddd<CR-LF> > aaa,,,<CR-LF> > aaa<CR-LF> > ,bbb<CR-LF> > ,,ccc<CR-LF> > ,,,ddd<CR-LF> > > The second and third line are the same - they just have a value in the > first field. > The csv reader should assume that if there are missing columns (ie commas) > then the values are null. > Leading null values still require the commas to be included (lines 4-6). > > This is useful when > a) the dataset is sparse. > b) the dataset has new columns added - the reader can still accept old > datafiles without them being considered 'malformed'. > > Microsoft Excel and Oracle SQL*Loader can already accept data with missing > (trailing) commas. > > > Tak Tang > > > >

1 0

Media Type "text/csv" - trailing nullcols
by Tak Tang 24 Mar '05

24 Mar '05

Hello, This is my first post, and I've entered the discussion late, so please excuse me if this has already been discussed . . . The draft (03) does not require that each record/line have the same number of values/commas. I think it may be benefitial to explicitly allow csv writers to omit trailing commas if there are no further non-null values. eg (all of these lines are valid) aaa,bbb,ccc,ddd<CR-LF> aaa,,,<CR-LF> aaa<CR-LF> ,bbb<CR-LF> ,,ccc<CR-LF> ,,,ddd<CR-LF> The second and third line are the same - they just have a value in the first field. The csv reader should assume that if there are missing columns (ie commas) then the values are null. Leading null values still require the commas to be included (lines 4-6). This is useful when a) the dataset is sparse. b) the dataset has new columns added - the reader can still accept old datafiles without them being considered 'malformed'. Microsoft Excel and Oracle SQL*Loader can already accept data with missing (trailing) commas. Tak Tang D I S C L A I M E R This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any views or opinions presented are solely those of the author and do not necessarily represent those of the Trust unless explicitly stated otherwise. If you have received this e-mail in error please delete the e-mail and contact the Southampton University Hospitals NHS Trust Helpdesk on:- 023 80796000 The information contained in this e-mail may be subject to public disclosure under the Freedom of Information Act 2000. Unless the Information is legally exempt from disclosure, the confidentiality of this e-mail and your reply cannot be guaranteed. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses.

1 0

Transport Area requests new/additional Media Type review for text/red
by Allison Mankin 24 Mar '05

24 Mar '05

The Transport Area requests a Media Type review for the proposed type text/red, intended for the IETF tree, as a Proposed Standard. The specification is http://www.ietf.org/internet-drafts/draft-ietf-avt-text-red-05.txt. This document had both a formal Applications AD Review and an active IETF Last Call discussion to date. During the latter, an approach of defining a "Restrictions on Usage" field for a sub-type in major type such as text that will be transported only by RTP was devised. The description of this field is found in draft-freed-media-reg-02.txt, currently in IETF Last Call itself. As the result of this, please review the following media registration for text/red instead of the one in the i-d (but read other sections in the i-d as needed): MIME media type name: text MIME subtype name: red Required parameters: rate: the RTP clock rate of the payload carried within the RTP packet. Typically, this rate is 1000, but other rates MAY be specified. This parameter MUST be set equal to the clock rate of the text payload format carried as the primary encoding. pt: a comma-separated ordered list of RTP payload types enumerating the primary, secondary, etc., in accordance with RFC 2198. Because comma is a special character, the list MUST be a quoted-string (enclosed in double quotes). For static payload types, each list element is simply the type number. For dynamic payload types, each list element is a mapping of the dynamic payload type number to an embedded MIME content- type specification for the payload format corresponding to the dynamic payload type. The format of the mapping is: dynamic-payload-type = content-type If the content-type string includes a comma, then the content- type string MUST be a quoted-string. If the content-type string does not include a comma, it MAY still be quoted. Since it is part of the list which must itself be a quoted-string, that means the quotation marks MUST be quoted with backslash quoting as specified in RFC 2045 [4]. If the content-type string itself contains a quoted-string, then the requirement for backslash quoting is recursively applied. Optional parameters: ptime, maxptime (these attributes are originally defined in RFC 2327 and RFC 3267 respectively) Restrictions on Usage: This type is defined only for transfer for RTP. It shall not be defined for a storage format. Encoding considerations: See Restrictions on Usage above; this section is included per the requirements in RFC 3555. Security considerations: Refer to section 5 of RFC XXXX. (XXXX is a reference to the RFC number to be assigned to draft-ietf-avt-text-red-0t.txt) Interoperability considerations: none Published specification: RFC XXXX. Applications which use this media type: Text streaming and conferencing tools. Additional information: none Person & email address to contact for further information: Paul E. Jones E-mail: paulej(a)packetizer.com Intended usage: COMMON Author: Paul E. Jones paulej(a)packetizer.com Change Controller: AVT Working Group delegated from the IESG Please provide any comments before 6 April 2005. Thanks, Allison

2 2

Type 'text/csv', draft-03
by Yakov Shafranovich 24 Mar '05

24 Mar '05

I posted a new version (-03) correcting the issue pointed out by Clyde Ingram. As a matter of fact while editing the draft, I noticed that the ABNF grammar did not allow commas as end of field markers for the last field and I changed the text to match. Copies of the draft can be found here (before it posts to the repository): http://www.shaftek.org/publications/drafts/mime-csv/draft-shafranovich-mime… http://www.shaftek.org/publications/drafts/mime-csv/draft-shafranovich-mime… HTML and text diff of changes: http://www.shaftek.org/publications/drafts/mime-csv/rfcdiff-02-to-03.html http://www.shaftek.org/publications/drafts/mime-csv/diff-02-to-03.txt Yakov

1 0