- Ietf-types - example.com

Request for review of InkML media type: application/inkml+xml
by Kazuyuki Ashimura 28 Jan '08

28 Jan '08

Dear list, W3C published a Last Call Working Draft for "Ink Markup Language (InkML)" at: http://www.w3.org/TR/2006/WD-InkML-20061023/ I am sending this request to ask the Ietf-types list for comments on the Media Type section of the InkML specification following the procedure defined at: http://www.w3.org/2002/06/registering-mediatype --- The Media Type section of the InkML specification is available at: http://www.w3.org/TR/2006/WD-InkML-20061023/#mime-definition and a plaintext copy is also available below. MIME media type name: ---------------------- application MIME subtype name: ------------------- inkml+xml Required parameters: --------------------- None. Optional parameters: --------------------- charset This parameter has identical semantics to the charset parameter of the application/xml media type as specified in [RFC3023]. Encoding considerations: ------------------------- By virtue of InkML content being XML, it has the same considerations when sent as "application/inkml+xml" as does XML. See RFC 3023, section 3.2. Security considerations: ------------------------- Several InkML instructions may cause arbitrary URIs to be dereferenced. In this case, the security issues of RFC1738, section 6, should be considered. In addition, because of the extensibility features for InkML, it is possible that "application/inkml+xml" may describe content that has security implications beyond those described here. However, if the processor follows only the normative semantics of this specification, this content will be ignored. Only in the case where the processor recognizes and processes the additional content, or where further processing of that content is dispatched to other processors, would security issues potentially arise. And in that case, they would fall outside the domain of this registration document. Interoperability considerations: --------------------------------- This specification describes processing semantics that dictate behavior that must be followed when dealing with, among other things, unrecognized elements. Because InkML is extensible, conformant "application/inkml+xml" processors can expect that content received is well-formed XML, but it cannot be guaranteed that the content is valid InkML or that the processor will recognize all of the elements and attributes in the document. Published specification: ------------------------- This media type registration is for InkML documents as described by this specification. Additional information: ------------------------- Magic number(s): There is no single initial octet sequence that is always present in InkML documents. File extension(s): InkML documents are most often identified with the extensions ".ink" or ".inkml". Macintosh File Type Code(s): TEXT Intended usage: ---------------- COMMON Author/Change controller: -------------------------- The InkML specification is a work product of the World Wide Web Consortium's Multimodal Interaction Working Group. The W3C has change control over these specifications. Normative References: ---------------------- [RFC3023] XML Media Types. IETF RFC 3023. http://www.ietf.org/rfc/rfc3023.txt . Sincerely, Kazuyuki -- Kazuyuki Ashimura / W3C Multimodal & Voice Activity Lead mailto: ashimura(a)w3.org voice: +81.466.49.1170 / fax: +81.466.49.1171

1 0

[resent] Request for review of EMMA media type: application/emma+xml
by Kazuyuki Ashimura 28 Jan '08

28 Jan '08

Dear list, # terribly sorry but resending this message, because apparently I used wrong # email address in my previous message... W3C published a Candidate Recommendation for "EMMA: Extensible MultiModal Annotation markup language" at: http://www.w3.org/TR/2007/CR-emma-20071211/ I am sending this request to ask the Ietf-types list for comments on the Media Type section of the EMMA specification following the procedure defined at: http://www.w3.org/2002/06/registering-mediatype --- The Media Type section of the EMMA specification is available at: http://www.w3.org/TR/2007/CR-emma-20071211/#appB and a plaintext copy is also available below. MIME media type name: ---------------------- application MIME subtype name: ------------------- emma+xml Required parameters: --------------------- None. Optional parameters: --------------------- charset This parameter has identical semantics to the charset parameter of the application/xml media type as specified in [RFC3023] or its successor. Encoding considerations: ------------------------- By virtue of EMMA content being XML, it has the same considerations when sent as "application/emma+xml"as does XML. See RFC 3023 (or its successor), section 3.2. Security considerations: ------------------------- Several features of EMMA require dereferencing arbitrary URIs. Implementers are advised to heed the security issues of [RFC3986] section 7. In addition, because of the extensibility features for EMMA, it is possible that "application/emma+xml" will describe content that has security implications beyond those described here. However, if the processor follows only the normative semantics of this specification, this content will be ignored. Only in the case where the processor recognizes and processes the additional content, or where further processing of that content is dispatched to other processors, would security issues potentially arise. And in that case, they would fall outside the domain of this registration document. Interoperability considerations: --------------------------------- This specification describes processing semantics that dictate the required behavior for dealing with, among other things, unrecognized elements. Because EMMA is extensible, conformant "application/emma+xml" processors MAY expect that content received is well-formed XML, but processors SHOULD NOT assume that the content is valid EMMA or expect to recognize all of the elements and attributes in the document. Published specification: ------------------------- This media type registration is for EMMA documents as described by this specification. Additional information: ------------------------ Magic number(s): There is no single initial octet sequence that is always present in EMMA documents. File extension(s): EMMA documents are most often identified with the extensions ".emma". Macintosh File Type Code(s): TEXT Person & email address to contact for further information: ----------------------------------------------------------- Kazuyuki Ashimura, <ashimura(a)w3.org>. Intended usage: ---------------- COMMON Author/Change controller: -------------------------- The EMMA specification is a work product of the World Wide Web Consortium's Multimodal Interaction Working Group. The W3C has change control over these specifications. Normative References: ---------------------- [RFC3023] M. Murata et al., editors. XML Media Types. IETF RFC 3023, January 2001 http://www.ietf.org/rfc/rfc3023.txt [RFC3986] T. Berners-Lee et al., editors. Uniform Resource Identifier (URI): Generic Syntax. IETF RFC 3986, January 2005. http://www.ietf.org/rfc/rfc3986.txt Sincerely, Kazuyuki -- Kazuyuki Ashimura / W3C Multimodal & Voice Activity Lead mailto: ashimura(a)w3.org voice: +81.466.49.1170 / fax: +81.466.49.1171

1 0

Request for review of EAI MIME types
by Harald Alvestrand 24 Jan '08

24 Jan '08

This is the formal request for review for the following media types that have been defined in the Email Address Internationalization WG, and published in the drafts draft-ietf-eai-utf8headers-08 draft-ietf-eai-dsn-05 The extracted templates are given below. For full context, read the drafts. If possible, keep the EAI WG copied on any substantive comments. Harald Alvestrand, EAI WG chair === message/global, from draft-ietf-eai-utf8headers-08 ===== Type name: message Subtype name: global Required parameters: none Optional parameters: none Encoding considerations: Any content-transfer-encoding is permitted. The 8-bit or binary content-transfer-encodings are recommended where permitted. Security considerations: See Section 6 Interoperability considerations: The media type provides functionality similar to the message/rfc822 content type for email messages with international email headers. When there is a need to embed or return such content in another message, there is generally an option to use this media type and leave the content unchanged or downconvert the content to message/rfc822. Both of these choices will interoperate with the installed base, but with different properties. Systems unaware of international headers will typically treat a message/global body part as an unknown attachment, while they will understand the structure of a message/ rfc822. However, systems which understand message/global will provide functionality superior to the result of a down-conversion to message/rfc822. The most interoperable choice depends on the deployed software. Published specification: RFC XXXX Applications that use this media type: SMTP servers and email clients that support multipart/report generation or parsing. Email clients which forward messages with international headers as attachments. Additional information: Magic number(s): none File extension(s): The extension ".u8msg" is suggested. Macintosh file type code(s): A uniform type identifier (UTI) of "public.utf8-email-message" is suggested. This conforms to "public.message" and "public.composite-content" but does not necessarily conform to "public.utf8-plain-text". Person & email address to contact for further information: See the Author's address section of this document. Intended usage: COMMON Restrictions on usage: This is a structured media type which embeds other MIME media types. The 8-bit or binary content-transfer- encoding MUST be used unless this media type is sent over a 7-bit only transport. Author: See Author's Address section of this document. Change controller: IETF Standards Process === Message/global-headers, from draft-ietf-eai-dsn-05 === Type name: message Subtype name: global-headers Required parameters: none Optional parameters: none Encoding considerations: This media type contains Internationalized Email Headers [I-D.ietf-eai-utf8headers] with no message body. Whenever possible, the 8-bit content transfer encoding SHOULD be used. When this media type passes through a 7-bit-only SMTP infrastructure it MAY be encoded with the base64 or quoted- printable content transfer encoding. Security considerations: See Section 7 Interoperability considerations: It is important this media type is not converted to a charset other than UTF-8. As a result, implementations MUST NOT include a charset parameter with this media type. Although it might be possible to downconvert this media type to the text/rfc822-header media type, such conversion is discouraged as it loses information. Published specification: RFC XXXX Applications that use this media type: UTF8SMTP servers and email clients that support multipart/report generation or parsing. Additional information: Magic number(s): none File extension(s): In the event this is saved to a file, the extension ".u8hdr" is suggested. Macintosh file type code(s): The 'TEXT' type code is suggested as files of this type are typically used for diagnostic purposes and suitable for analysis in a UTF-8 aware text editor. A uniform type identifier (UTI) of "public.utf8-email-message-header" is suggested. This type conforms to "public.utf8-plain-text" and "public.plain-text". Person & email address to contact for further information: See the Author's address section of this document. Intended usage: COMMON Restrictions on usage: This media type contains textual data in the UTF-8 charset. It typically contains octets with the 8th bit set. As a result a transfer encoding is required when a 7-bit transport is used. Author: See Author's Address section of this document. Change controller: IETF Standards Process === Message/global-delivery-status, from draft-ietf-eai-dsn-05 === Type name: message Subtype name: global-delivery-status Required parameters: none Optional parameters: none Encoding considerations: This media type contains delivery status notification attributes in the UTF-8 charset. The 8-bit content transfer encoding MUST be used with this content-type, unless it is sent over a 7-bit transport environment in which case quoted- printable or base64 may be necessary. Security considerations: See Section 7 Interoperability considerations: This media type provides functionality similar to the message/delivery-status content type for email message return information. Clients of the previous format will need to be upgraded to interpret the new format, however the new media type makes it simple to identify the difference. Published specification: RFC XXXX Applications that use this media type: SMTP servers and email clients that support delivery status notification generation or parsing. Additional information: Magic number(s): none File extension(s): The extension ".u8dsn" is suggested. Macintosh file type code(s): A uniform type identifier (UTI) of "public.utf8-email-message-delivery-status" is suggested. This type conforms to "public.utf8-plain-text". Person & email address to contact for further information: See the Author's address section of this document. Intended usage: COMMON Restrictions on usage: This is expected to be the second part of a multipart/report. Author: See Author's Address section of this document. Change controller: IETF Standards Process === Message/global-disposition-notification, from draft-ietf-eai-dsn-05 === Type name: message Subtype name: global-disposition-notification Required parameters: none Optional parameters: none Encoding considerations: This media type contains disposition notification attributes in the UTF-8 charset. The 8-bit content transfer encoding MUST be used with this content-type, unless it is sent over a 7-bit transport environment in which case quoted- printable or base64 may be necessary. Security considerations: See Section 7 Interoperability considerations: This media type provides functionality similar to the message/disposition-notification content type for email message disposition information. Clients of the previous format will need to be upgraded to interpret the new format, however the new media type makes it simple to identify the difference. Published specification: RFC XXXX Applications that use this media type: Email clients or servers that support message disposition notification generation or parsing. Additional information: Magic number(s): none File extension(s): The extension ".u8mdn" is suggested. Macintosh file type code(s): A uniform type identifier (UTI) of "public.utf8-email-message-disposition-notification" is suggested. This type conforms to "public.utf8-plain-text". Person & email address to contact for further information: See the Author's address section of this document. Intended usage: COMMON Restrictions on usage: This is expected to be the second part of a multipart/report. Author: See Author's Address section of this document. Change controller: IETF Standards Process

2 1

Re: Re: Unknown text/* subtypes
by Eric Prud'hommeaux 18 Jan '08

18 Jan '08

* Ian Hickson <ian(a)hixie.ch> [2008-01-13 05:47+0000] > On Fri, 28 Dec 2007, Frank Ellermann wrote: > > > > Years later (after 2616bis) it might be possible to upgrade "default > > ASCII" to UTF-8, Latin-1 was a dead end. As soon as we're back to > > "default ASCII" just let RFC 2277 finish it off. > > FWIW, a number of specs are already overriding both MIME and HTTP when it > comes to character encodings. For example HTML4 says to not default to any > encoding at all [1], CSS defaults to a complicated heuristic [2], HTML5 as > currently proposed defaults to an even more complicated heuristic [3], and > so on. > > In the "real world" the implementations are following the heuristics > described in CSS2.1 and HTML5 (or something close to them), and those > differ for text/css and text/html, so it would seem pointless for HTTP to > try to define something here: it would just get ignored. > > IMHO the best option is for HTTP to stay out of the discussion altogether > and let the lower level specs (MIME) and the higher level specs (XML, > HTML, CSS, etc, defining the formats) figure it out amongst themselves. I think this is consistent with Martin's proposal that HTTP1.1bis not set a default encoding http://www.w3.org/2008/01/rdf-media-types#noDefault (noting that Frank Ellerman believed the default should be us-ascii for the same effect) http://www.w3.org/2008/01/rdf-media-types#defAscii What we still need, however, is an update to 2046 that reflects current practice (and eases the discovery process for folks registering non-ascii text/ media types). Let's geek out the changes to we'd like to see. • CRLF rules: [[ The canonical form of any MIME "text" subtype MUST always represent a line break as a CRLF sequence. Similarly, any occurrence of CRLF in MIME "text" MUST represent a line break. Use of CR and LF outside of line break sequences is also forbidden. ]] — RFC2046 §4.1.1 ¶1 http://www.rfc.net/rfc2046.html#s4.1.1. is not respected by HTTP1.1, nor is it respected in general when shipping text/xml. Does anyone rely on any vestige of this rule (e.g. mail clients, MTAs, web servers, proxies or clients)? I would like to think that MIME shouldn't care about recognizing new lines in the text block. If it can't go away, can it be relaxed in accordance with HTTP 1.1 [[ The line terminator for message-header fields is the sequence CRLF. However, we recommend that applications, when parsing such headers, recognize a single LF as a line terminator and ignore the leading CR. ]] — RFC2616 §19.3 ¶3 http://www.rfc.net/rfc2616.html#s19.3 or XML 1.1 (which includes NEXT LINE (NEL) and LINE SEPARATOR): [[ 1. the two-character sequence #xD #xA 2. the two-character sequence #xD #x85 3. the single character #x85 4. the single character #x2028 5. any #xD character that is not immediately followed by #xA or #x85. ]] — XML 1.1 §2.11 ¶2 http://www.w3.org/TR/xml11/#sec-line-ends The XML 1.1 rule interacts with character encoding because, while most character encodings line up with ascii on CR and LF, clearly none do on #x85 and #x2028 • character encoding: [[ Unlike some other parameter values, the values of the charset parameter are NOT case sensitive. The default character set, which must be assumed in the absence of a charset parameter, is US-ASCII. The specification for any future subtypes of "text" must specify whether or not they will also utilize a "charset" parameter, and may possibly restrict its values as well. For other subtypes of "text" than "text/plain", the semantics of the "charset" parameter should be defined to be identical to those specified here for "text/plain", i.e., the body consists entirely of characters in the given charset. In particular, definers of future "text" subtypes should pay close attention to the implications of multioctet character sets for their subtype definitions. The charset parameter for subtypes of "text" gives a name of a character set, as "character set" is defined in RFC 2045. The rules regarding line breaks detailed in the previous section must also be observed -- a character set whose definition does not conform to these rules cannot be used in a MIME "text" subtype. ]] — RFC2046 §4.1.2 ¶2-4 http://www.rfc.net/rfc2046.html#s4.1.2. When should the "default" character set apply? • no charset parameter • no charset parameter, no fixed encoding for the media type • no charset, no fixed encoding, no internal encoding declaration The current text specifies the first, while HTML and CSS count on the third. From the use case of "best effort rendering", we are already in a state where users who are better-informed than their web or mail clients manually set the encoding so they can see the right characters. The following heuristics may meet or exceed the user experience with today's data while advancing the state of the art to enable better rendering with future data: [[ Unlike some other parameter values, the values of the charset parameter are NOT case sensitive. The first of the following determinants that apply will identify the character set: 1. charset parameter 2. fixed encoding registered with the media type, if known 3. encoding algorithm registered with the media type, if known 4. UFT-8 if the document conforms to the UTF-8 encoding pattern 5. ISO-8859-1 if all the octets are in [\r\n\x20-\x7e] 6. application preference ]] @@charset constraints — can it have faux line feeds? @@bidi? Martin, what do you think? @@lowest common demoninator: RFC2046 §4.1.2 ¶22 http://www.rfc.net/rfc2046.html#s4.1.2. Is it better to encourage the world to write "UTF-8" or "US-ASCII" for ascii subset? tension between lcd and one common encoding. @@Content-Transfer-Encoding: Base64 Content-Type: text/wibbly How does TE affect this? I suspect it's completely orthogonal. > -- Footnotes -- > > [1] http://www.w3.org/TR/html4/charset.html#h-5.2.2 > This text explicitly says that HTTP's default is useless. It then > recomments behaviour that is even more useless, but that's another > problem altogether... > > [2] http://www.w3.org/TR/CSS21/syndata.html#charset > > [3] http://www.whatwg.org/specs/web-apps/current-work/multipage/section-parsing… > > Cheers, > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' -- -eric office: +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA mobile: +1.617.599.3509 (eric(a)w3.org) Feel free to forward this message to any list for any purpose other than email address distribution.

2 3

Request for review of Turtle (an RDF serialization) media type: text/turtle
by Eric Prud'hommeaux 17 Jan '08

17 Jan '08

W3C is about to publish a Team Submission for the RDF serialization Turtle. A mockup of the document to be published is at http://www.w3.org/2007/11/21-turtle Because the document will include the text of the media type registration, I am vetting this registration with ietf-types before publishing the document. Some discussion about the claim to force utf-8 encoding (and not require that in a charset parameter) can be seen at http://lists.w3.org/Archives/Public/www-archive/2007Dec/ (Subject: Media types for RDF languages N3 and Turtle) I got moderator-actioned for having too many folks in the Cc so I'm Bcc'ing them all in this request for review: "Sean B. Palmer" <sean(a)miscoranda.com>, Tim Berners-Lee <timbl(a)w3.org>, "Daniel W. Connolly" <connolly(a)w3.org>, Dave Beckett <dave(a)dajobe.org>, Lee Feigenbaum <lee(a)thefigtrees.net>, Garret Wilson <garret(a)globalmentor.com>, Graham Klyne <GK(a)ninebynine.org>, Dan Brickley <danbri(a)danbri.org>, Type name: text Subtype name: turtle Required parameters: None Optional parameters: None Encoding considerations: The syntax of Turtle is expressed over code points in Unicode[UNICODE]. The encoding is always UTF-8 [RFC3629]; the charset parameter is not needed; though it may be included so long as the value is 'UTF-8'. Unicode code points may also be expressed using an \uXXXX (U+0 to U+FFFF) or \UXXXXXXXX syntax (for U+10000 onwards) where X is a hexadecimal digit [0-9A-F] Security considerations: Turtle uses IRIs as term identifiers. Applications interpreting data expressed in Turtle sould address the security issues of Internationalized Resource Identifiers (IRIs) Section 8, as well as Uniform Resource Identifier (URI): Generic Syntax [RFC3986] Section 7 Multiple IRIs may have the same appearance. Characters in different scripts may look similar (a Cyrillic "o" may appear similar to a Latin "o"). A character followed by combining characters may have the same visual representation as another character (LATIN SMALL LETTER E followed by COMBINING ACUTE ACCENT has the same visual representation as LATIN SMALL LETTER E WITH ACUTE). Any person or application that is writing or interpreting data in Turtle must take care to use the IRI that matches the intended semantics, and avoid IRIs that make look similar. Further information about matching of similar characters can be found in Unicode Security Considerations [UNISEC] and Internationalized Resource Identifiers (IRIs) [RFC3987] Section 8. Interoperability considerations: There are no known interoperability issues. Published specification: TBD, in the mean time, see http://www.w3.org/2007/11/21-turtle Applications which use this media type: No widely deployed applications are known to use this media type. It may be used by some web services and clients consuming their data. Additional information: Magic number(s): Turtle documents may have the strings '@prefix' or '@base' (case dependent) near the beginning of the document. File extension(s): ".ttl" Base URI: The Turtle '@base <IRIref>' term can change the current base URI for relative IRIrefs in the query language that are used sequentially later in the document. Macintosh file type code(s): "TEXT" Person & email address to contact for further information: Eric Prud'hommeaux <eric(a)w3.org> Intended usage: COMMON Restrictions on usage: None Author/Change controller: The Turtle specification is the product of David Beckett and Tim Berners-Lee. A W3C Working Group may assume maintenance of this document; W3C reserves change control over this specifications. Normative References [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001. [RFC3629] F. Yergeau, "UTF-8, a transformation format of ISO 10646", RFC 3629, November 2003. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005. [UNICODE] The Unicode Standard, Version 4. ISBN 0-321-18578-1, as updated from time to time by the publication of new versions. The latest version of Unicode and additional information on versions of the standard and of the Unicode Character Database is available at http://www.unicode.org/unicode/standard/versions/. [UNISEC] Mark Davis, Michel Suignard, "Unicode Security Considerations. http://www.unicode.org/reports/tr36/ -- -eric office: +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA mobile: +1.617.599.3509 (eric(a)w3.org) Feel free to forward this message to any list for any purpose other than email address distribution.

9 17

Request for review of Ogg Media Types: video/ogg, audio/ogg, application/ogg
by Ivo Emanuel Gonçalves 16 Jan '08

16 Jan '08

This is a request for review of the Ogg Media Types video/ogg, audio/ogg, and application/ogg, which are described in draft-goncalves-rfc3534bis-00 [1]. Comments are welcome. If discussion regarding those types is better suited in split messages instead of one thread, please advise if that is the case. Regards, Ivo [1] http://www.ietf.org/internet-drafts/draft-goncalves-rfc3534bis-00.txt

5 8

Re: Unknown text/* subtypes
by Frank Ellermann 16 Jan '08

16 Jan '08

Ian Hickson wrote: > For example HTML4 says to not default to any encoding at all [1] [...] Yes, but HTTP has to work for plain text, pre-HTML 4, etc., and I think HHTP needs its own idea of what is allowed in a HTTP header. If one side refuses to say what the body is the other side needs a working assumption for the job at hand (= HTTP transmission). How browsers display a body (if at all) is a different question. "Assume it's something remotely related to ASCII, i.e. all octets that could be ASCII actually are ASCII" is good enough for HTTP, isn't it ? I don't see where "assume Latin-1" is actually needed today with respect to *HTTP*, even for HTML 2 (or arguably 3.2). The W3C validator ignores this HTML detail - AFAIK I'm the only user who ever asked if that's as it should be. It is irrelevant outside of validator torture tests... :-) > it would seem pointless for HTTP to try to define something > here: it would just get ignored. I think we mean the same thing when I propose that it's pointless to define "something different from MIME" in the HTTP spec., a normative MIME reference (+ explanation of the change) will do. Frank

2 2

Re: [RESEND] Media types for RDF languages N3 and Turtle
by Eric Prud'hommeaux 04 Jan '08

04 Jan '08

BCc'ing "Sean B. Palmer" <sean(a)miscoranda.com>, Tim Berners-Lee <timbl(a)w3.org>, "Daniel W. Connolly" <connolly(a)w3.org>, Dave Beckett <dave(a)dajobe.org>, Lee Feigenbaum <lee(a)thefigtrees.net>, Garret Wilson <garret(a)globalmentor.com>, Graham Klyne <GK(a)ninebynine.org>, Dan Brickley <danbri(a)danbri.org>, to avoid getting moderator-actioned. Please do the same if you wish to include these people in the conversation. I've summarized a lot of the issues around text/ media types in http://www.w3.org/2008/01/rdf-media-types I'm not done vetting all the comments I've recieved, but I'm getting on a plane and I'd like if folks could take a look and make suggestions. -- -eric office: +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA mobile: +1.617.599.3509 (eric(a)w3.org) Feel free to forward this message to any list for any purpose other than email address distribution.

1 0

Re: Media types for RDF languages N3 and Turtle
by Sean B. Palmer 31 Dec '07

31 Dec '07

On Dec 17, 2007 3:22 PM, Garret Wilson <garret(a)globalmentor.com> wrote: > There exists serious concern regarding the use of a text top-level > type for N3. See the recent discussion on www-rdf-comments. Eric and I discussed that in some detail prior to and subsequent to the start of this thread. One thing that I don't understand is what you said here: [[[ I suppose that, with the popular understanding that RFC 2046 requires a default character set of US-ASCII if there is no charset parameter, then it's almost as true as if RFC 2046 said so explicitly. ]]] - http://lists.w3.org/Archives/Public/www-rdf-comments/2007OctDec/0017 It seems very clear to me that RFC 2046 states explicitly that US-ASCII is required if there is no charset parameter. Here are the relevant quotes: The default character set, which must be assumed in the absence of a charset parameter, is US-ASCII. ... Note that the character set used, if anything other than US- ASCII, must always be explicitly specified in the Content-Type field. The way I read that, that doesn't leave any room for a text/anything specification setting its own default. As for the CRLF requirement, that CRLF and *only* CRLF be used for line breaks, Dan Brickley commented in response to that that text/xml was widely regarded troublesome; but it's not clear from his citations that CRLF has anything to do with the troublesome nature, only charset defaulting. It seems that most of the problem, as you mentioned in the www-rdf-comments thread, is that the text subtree is simply broken. RFC 2046 just wasn't written to deal with the Unicode world. Check out the following, for example: A SINGLE character set that can be used universally for representing all of the world's languages in Internet mail would be preferrable. Unfortunately, existing practice in several communities seems to point to the continued use of multiple character sets in the near future. A small number of standard character sets are, therefore, defined for Internet use in this document. And it defines US-ASCII and ISO-8859-X. It's not RFC 2046's fault that it wasn't prescient, but it's *out-of-date* now and perhaps ought to be obsoleted so that text/* can be used as intended rather than as we're currently forced? But of course there is the question of what MIME implementations will do and what problems, possibly serious, it would cause to, for example, make utf-8 the new text/* default. It would need a lot of discussion and a new RFC. Note that TimBL has never, as far as I know, suggested disregarding the charset defaulting requirement, just the CRLF requirement which he mightn't even be aware of. And as it seems that the charset defaulting is the thing that most people are anxious about, I'd be happy for text/rdf+n3; charset=utf-8 or text/n3; charset=utf-8 to go forwards, even ignoring the fact that it disregards the CRLF requirement. Thanks, -- Sean B. Palmer, http://inamidst.com/sbp/

2 4

Re: [RESEND] Media types for RDF languages N3 and Turtle
by Garret Wilson 21 Dec '07

21 Dec '07

Graham Klyne wrote: > (1) use application/(something) rather than text/(something) in *all* cases > where the content is not primarily for human consumption - i.e. if you expect to > do anything other than display as-is on a character display. I think the last part of that sentence is definitely too far---the only thing that would be displayed "as-is on a character display" is text/plain. Besides plain text, "primarily for human consumption" is one possible criterion, but is that the most useful criterion? RFC 2046 mentions, "The 'text' media type is intended for sending material which is principally textual in form." I don't know what that means exactly, but the RFC goes on to say things in this category are "to some extent readable" and that, "It is useful, then, to distinguish them, at the highest level, from such unreadable data as images, audio, or text represented in an unreadable form." I don't have a strong opinion here, but I will point out that RFC 2046 talks about the category being "the highest level" division and that it is "useful". To me, it is useful at a high level to note that the content types discussed here have the following characteristics: * The content bytes are interpreted as text characters (i.e. Unicode code points); ignoring encoding, no bytes are interpreted as anything other than text characters. (These text characters may later be subject to some meta-interpretation---e.g. delimiters---but they are first interpreted as text characters.) * These content types can always be edited in a text editor. * Abstract values, such as numbers, are represented by their text lexical forms, not by some non-text encoding. To me those points are meaningful, and it might be useful to include those criteria when making a high-level distinction. Is the top-level type of RFC 2046 even useful anymore? I think the biggest criteria for me is, "can I edit this thing in a text editor?" Whether the author meant the information to be directly displayed to the user, while interesting, seems less useful from a content-processing point of view. Garret

1 1