- Ietf-types - alvestrand.no

Transport Area requests Media Type review for application/conference-info+xml
by Allison Mankin 21 Apr '05

21 Apr '05

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

1 0

For review: application/atom+xml
by Mark Nottingham 20 Apr '05

20 Apr '05

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 <mnot(a)pobox.com> Intended usage: COMMON Author/Change controller: This specification's author(s). [[anchor61: update upon publication]] --->8--- -- Mark Nottingham http://www.mnot.net/

3 4

Transport Area requests Media Type review for audio/BV16 and audio/BV32
by Allison Mankin 06 Apr '05

06 Apr '05

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

1 0

Type 'text/csv', draft-04
by Yakov Shafranovich 05 Apr '05

05 Apr '05

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… 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-03-to-04.html http://www.shaftek.org/publications/drafts/mime-csv/diff-03-to-04.txt Yakov

1 1

please review draft-froumentin-voice-mediatypes-00
by Max Froumentin 04 Apr '05

04 Apr '05

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 <web-human(a)w3.org> 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 <web-human(a)w3.org> 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 ietf-ipr(a)ietf.org. 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]

1 0

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