Subject: Request for review of InkML media type: application/inkml+xml
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Mon Jan 28 20:45:20 2008

Kazuyuki Ashimura wrote:

> the security issues of RFC1738, section 6, should be considered.

Please s/RFC1738, section 6/RFC3986, section 7/ if you have no
special reasons to use the almost completely obsolete RFC 1738.

> Published specification:
> -------------------------
> 
> This media type registration is for InkML documents as described
> by this specification.

IMO you need a reference for "this" specification, IANA publishes
only your registration template, where "this" would make no sense.

 Frank

From: ashimura at w3.org (Kazuyuki Ashimura)
Date: Mon Jan 28 20:10:42 2008
Subject: [resent] Request for review of EMMA media type: application/emma+xml
Message-ID: <[email-masked]>

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, <[email-masked]>.

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: [email-masked]
voice: +81.466.49.1170 / fax: +81.466.49.1171

From: distobj at acm.org (Mark Baker)
Date: Thu Jan 24 21:13:21 2008
Subject: Request for review of EAI MIME types
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

I'm no subject matter expert in this space, but everything looks in
order from a registration process POV.  The security considerations
sections weren't included in your message, but are found in the
drafts, and they appear fine.

Mark.
>From [email-masked]  Mon Jan 28 19:38:22 2008
From: ashimura at w3.org (Kazuyuki Ashimura)
Date: Mon Jan 28 20:10:41 2008
Subject: Request for review of InkML media type: application/inkml+xml
Message-ID: <[email-masked]>

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: [email-masked]
voice: +81.466.49.1170 / fax: +81.466.49.1171

From: eric at w3.org (Eric Prud'hommeaux)
Date: Fri Jan 18 00:49:54 2008
Subject: Unknown text/* subtypes
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

* Ned Freed <[email-masked]> [2008-01-13 16:26-0800]
> > * Ian Hickson <[email-masked]> [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.
> 
> You might, and I emphasize might, be able to get this changed to protocol
> specific restriction. (The MIME specifications specify both an email-specific
> extension as well as some more generally useful facilities.) There is no chance
> of this rule being lifted in general.
> 
> > ? 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)?
> 
> Not only does email depend on this, conformance to this has been dramatically
> strengthened, not weakened, in subsequest revisions of the email protocol
> specification. Specifically, RFC 821 was essentially silent on what bare CR and
> LF mean, but 2821 and 2821bis (now in last call) both say that bare CR and LF
> MUST NOT be sent and if received MUST NOT be treated as CRLF.

I guess we can measure compliance by what causes the clients to wrap
lines. Attached is a set of documents in different encodings, each
served with text/x-unknown and no charset. I expet this is a violation
of 2046, but I wanted to see what clients actually do.

These documents are also available on the web:

http://www.w3.org/2008/01/text/CRLF.txu		    CRs and LFs
http://www.w3.org/2008/01/text/latin-1-diac.txu	    d???r?t?c?ls in latin-1
http://www.w3.org/2008/01/text/utf-8-diac.txu	    d???r?t?c?ls in utf-8
http://www.w3.org/2008/01/text/utf-8-cyrillic.txu   ???????? in utf-8
http://www.w3.org/2008/01/text/utf-8-kanji.txu	    ?? in utf-8
http://www.w3.org/2008/01/text/shift-jis-kanji.txu  ?? in shift_jis

and their behavior in various web clients is documented at
  http://esw.w3.org/topic/ConformanceNotes

> This, incidentially, is not the way I personally think things should have been
> done. I like the "ignore bare CR treat LF like CRLF" approach. But my personal
> opinion isn't especially relevant - I mention it only to avoid "shoot the
> messenger" sorts of responses.
> 
> > I would like to think that MIME
> > shouldn't care about recognizing new lines in the text block.
> 
> I'm sorry, but that's fanciful in the extreme.

Let me try provide a concrete argument against my proposal:

"Mail, News and HTTP clients all need to render text/ stuff on the
screen, and a shared understanding of CRLF is essential to the user
experience."

> > 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
> 
> Again, I personally think this is the way to go. But that's not what
> has happened.

It's not what happened spec-wise, but I'm using this to see what happened
in the implementations.

> > 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
> > ]]
> 
> Again, there is absolutely no chance this will fly for email so it cannot be 
> written with this degree of generality. And if this is made protocol specific
> the specifics of any protocol other than email don't belong in a RFC 2046
> revision.

fair point. HTTP1.1bis folks may want to consider this.

> > @@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.
> 
> Marking something as utf-8 when it is in fact restricted to the us-ascii subset
> has been known to cause problems. I think change in this area is unlikely.

tx for your thoughts and attention on this.

> 				Ned

@@is a "no-change revision" is changing things if it
documents current practice contrary to the old spec.
-- 
-eric

office: +1.617.258.5741 32-G528, MIT, Cambridge, MA 02144 USA
mobile: +1.617.599.3509

([email-masked])
Feel free to forward this message to any list for any purpose other than
email address distribution.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 481 bytes
Desc: Digital signature
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20080117/9b338835/attachment.bin
>From [email-masked]  Fri Jan 18 01:13:34 2008
From: eric at w3.org (Eric Prud'hommeaux)
Date: Fri Jan 18 01:14:28 2008
Subject: Unknown text/* subtypes
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 481 bytes
Desc: Digital signature
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20080117/c56a6d37/attachment.bin
>From [email-masked]  Mon Jan 21 11:35:32 2008
From: harald at alvestrand.no (Harald Alvestrand)
Date: Mon Jan 21 11:35:40 2008
Subject: Request for review of EAI MIME types
Message-ID: <[email-masked]>

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

From: justivo at gmail.com (=?UTF-8?Q?Ivo_Emanuel_Gon=C3=A7alves?=)
Date: Wed Jan 16 05:36:31 2008
Subject: Request for review of Ogg Media Types: video/ogg, audio/ogg, application/ogg
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 1/15/08, Magnus Westerlund <[email-masked]> wrote:
> I am willing to become the sponsoring AD for this document. Please
> submit an updated internet draft and then notify me personally when you
> are satisfied with the draft and think it is ready to be published.

Thank you.  I will do so.

Regards,
Ivo
>From [email-masked]  Thu Jan 17 19:57:29 2008
From: LMM at acm.org (Larry Masinter)
Date: Thu Jan 17 20:03:57 2008
Subject: Unknown text/* subtypes
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]><[email-masked]>	<6.0.0.20.2.20071226102314.083e2170@localhost>	<[email-masked]>
	<[email-masked]>
Message-ID: <001b01c8593a$d36de8f0$7a49bad0$@org>

(bcc: http-wg because this is about the ietf-types proposal for RDF types)

I think it would be good to separate out the discussion of HTTP & browser
behavior from the MIME registrations of RDF representations. 

The simple solution for Media Types for RDF languages is -- if you really
want to use text/*, then always use a charset parameter, even if you'd
rather not. 

Don't try to change MIME behavior or update the default or otherwise mess
with it. You can say, using current MIME, what you want to say. Perhaps the
default to US-ASCII is annoying, the content-type string is longer than you
would like, but changing MIME is unnecessary.

Secondly, don't use use the '+' syntax, as in: text/rdf+n3, text/rdf+turtle
since it doesn't fit into the paradigm established for +xml; this was noted
during the discussion of registration of +zip types.

For an alternative, I imagine there are lots of possibilities. Personally, I
prefer being more explicit, e.g.,

Label N3 documents as:
     text/w3c.rdf.n3;charset=utf-8

label Turtle files as:
     text/w3c.rdf.turtle;charset=utf-8

Larry

From: justivo at gmail.com (=?UTF-8?Q?Ivo_Emanuel_Gon=C3=A7alves?=)
Date: Tue Jan 15 04:15:52 2008
Subject: Request for review of Ogg Media Types: video/ogg, audio/ogg, application/ogg
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hello Simon,

On 1/14/08, Simon Josefsson <[email-masked]> wrote:
> There is a reference for base64 to RFC2397 which
>looks odd to me, please consider to use RFC4648 instead.

You are right.

I wonder: is there a way to make this minor change without resetting
the time counter?  It would be nice if it would not necessary to wait
one more month until the media types are accepted by IANA.  Or maybe
IANA does not need to wait until the I-D becomes accepted as an RFC?

> Thanks for including the liberal 'Copying Conditions' section, which
> makes it possible to include the document in free software packages.

Thank you for the appreciation.

Regards,
Ivo
>From [email-masked]  Tue Jan 15 05:04:48 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue Jan 15 05:05:07 2008
Subject: Request for review of Ogg Media Types: video/ogg, audio/ogg,
 application/ogg
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Ivo Emanuel Gon?alves wrote:
> Hello Simon,
> 
> On 1/14/08, Simon Josefsson <[email-masked]> wrote:
>> There is a reference for base64 to RFC2397 which
>> looks odd to me, please consider to use RFC4648 instead.
> 
> You are right.
> 
> I wonder: is there a way to make this minor change without resetting
> the time counter?  It would be nice if it would not necessary to wait
> one more month until the media types are accepted by IANA.  Or maybe
> IANA does not need to wait until the I-D becomes accepted as an RFC?

That kind of correction should happen during AUTH48. No need to reset 
any counters.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20080114/8e409b28/smime.bin
>From [email-masked]  Tue Jan 15 11:24:24 2008
From: magnus.westerlund at ericsson.com (Magnus Westerlund)
Date: Tue Jan 15 11:24:36 2008
Subject: Request for review of Ogg Media Types: video/ogg, audio/ogg,
 application/ogg
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Ivo Emanuel Gon?alves skrev:
> Hello Simon,
> 
> On 1/14/08, Simon Josefsson <[email-masked]> wrote:
>> There is a reference for base64 to RFC2397 which
>> looks odd to me, please consider to use RFC4648 instead.
> 
> You are right.
> 
> I wonder: is there a way to make this minor change without resetting
> the time counter?  It would be nice if it would not necessary to wait
> one more month until the media types are accepted by IANA.  Or maybe
> IANA does not need to wait until the I-D becomes accepted as an RFC?
> 

The timer for the IETF types list review is not normally reset for minor 
corrections. Only substantial or controversial ones really need a 
reissued review period. There will also be time at the IETF last call to 
make a second review.

However, I get the impression that you misunderstand how and when the 
update will happen. As this media type is in the standard tree and was 
registered by an IETF standards track document, the only way of updating 
it is to publish an RFC that obsoletes the previous one. Thus your 
updated document needs to get AD sponsored and be approved by the IESG 
before the update can happen. After the approval IANA will update the 
media types registry to point at the new RFC.

I am willing to become the sponsoring AD for this document. Please 
submit an updated internet draft and then notify me personally when you 
are satisfied with the draft and think it is ready to be published.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

From: eric at w3.org (Eric Prud'hommeaux)
Date: Sun Jan 13 19:41:08 2008
Subject: Unknown text/* subtypes
In-Reply-To: <[email-masked]>
References: <[email-masked]> <6.0.0.20.2.20071226102314.083e2170@localhost> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

* Ian Hickson <[email-masked]> [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.html#determining
> 
> 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

([email-masked])
Feel free to forward this message to any list for any purpose other than
email address distribution.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 481 bytes
Desc: Digital signature
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20080113/96f92a01/attachment.bin
>From [email-masked]  Mon Jan 14 01:26:01 2008
From: ned.freed at mrochek.com (Ned Freed)
Date: Mon Jan 14 01:44:11 2008
Subject: Unknown text/* subtypes
In-Reply-To: "Your message dated Sun, 13 Jan 2008 13:40:12 -0500"
	<[email-masked]>
Message-ID: <[email-masked]>

> * Ian Hickson <[email-masked]> [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.

You might, and I emphasize might, be able to get this changed to protocol
specific restriction. (The MIME specifications specify both an email-specific
extension as well as some more generally useful facilities.) There is no chance
of this rule being lifted in general.

> ? 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)?

Not only does email depend on this, conformance to this has been dramatically
strengthened, not weakened, in subsequest revisions of the email protocol
specification. Specifically, RFC 821 was essentially silent on what bare CR and
LF mean, but 2821 and 2821bis (now in last call) both say that bare CR and LF
MUST NOT be sent and if received MUST NOT be treated as CRLF.

This, incidentially, is not the way I personally think things should have been
done. I like the "ignore bare CR treat LF like CRLF" approach. But my personal
opinion isn't especially relevant - I mention it only to avoid "shoot the
messenger" sorts of responses.

> I would like to think that MIME
> shouldn't care about recognizing new lines in the text block.

I'm sorry, but that's fanciful in the extreme.

> 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

Again, I personally think this is the way to go. But that's not what
has happened.

> 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
> ]]

Again, there is absolutely no chance this will fly for email so it cannot be 
written with this degree of generality. And if this is made protocol specific
the specifics of any protocol other than email don't belong in a RFC 2046
revision.

> @@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.

Marking something as utf-8 when it is in fact restricted to the us-ascii subset
has been known to cause problems. I think change in this area is unlikely.

				Ned
>From [email-masked]  Mon Jan 14 13:53:33 2008
From: justivo at gmail.com (=?UTF-8?Q?Ivo_Emanuel_Gon=C3=A7alves?=)
Date: Mon Jan 14 14:18:53 2008
Subject: Request for review of Ogg Media Types: video/ogg, audio/ogg,
	application/ogg
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Hello list,

This is the continuation to a thread started by me roughly a month
ago.  As a reminder, anyone may still post feedback regarding the Ogg
media types described in [1].  Feedback regarding good and bad aspects
is equally welcome.

So far, only Mr Ellermann commented on the registration proposal.
Please don't feel shy.

-Ivo

[1] http://www.ietf.org/internet-drafts/draft-goncalves-rfc3534bis-00.txt
>From [email-masked]  Mon Jan 14 14:34:00 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon Jan 14 14:34:15 2008
Subject: Request for review of Ogg Media Types: video/ogg, audio/ogg,
	application/ogg
In-Reply-To: <[email-masked]>
	("Ivo Emanuel =?iso-8859-1?Q?Gon=E7alves=22's?= message of "Mon, 14 Jan
	2008 12:53:33 +0000")
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

"Ivo Emanuel Gon?alves" <[email-masked]> writes:

> Hello list,
>
> This is the continuation to a thread started by me roughly a month
> ago.  As a reminder, anyone may still post feedback regarding the Ogg
> media types described in [1].  Feedback regarding good and bad aspects
> is equally welcome.

I read the draft, and it looks fine to me.  There is a reference for
base64 to RFC2397 which looks odd to me, please consider to use RFC4648
instead.

Thanks for including the liberal 'Copying Conditions' section, which
makes it possible to include the document in free software packages.

Thanks,
Simon
>From [email-masked]  Tue Jan 15 04:12:32 2008
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Tue Jan 15 04:12:29 2008
Subject: Unknown text/* subtypes
References: <[email-masked]>
	<[email-masked]><[email-masked]>
	<6.0.0.20.2.20071226102314.083e2170@localhost>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

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

From: ian at hixie.ch (Ian Hickson)
Date: Tue Jan 15 16:37:32 2008
Subject: Unknown text/* subtypes
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]><[email-masked]> <6.0.0.20.2.20071226102314.083e2170@localhost> <[email-masked]>
Message-ID: <[email-masked]>

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.

-- 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.html#determining

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>From [email-masked]  Tue Jan 15 08:08:44 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue Jan 15 16:37:33 2008
Subject: Unknown text/* subtypes
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]><[email-masked]>
	<6.0.0.20.2.20071226102314.083e2170@localhost>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Tue, 15 Jan 2008, Frank Ellermann wrote:
> >
> > For example HTML4 says to not default to any encoding at all [1]
> [...]
> 
> Yes, but HTTP has to work for plain text

RFC 2046 handles that.

> pre-HTML 4

HTML5 defines processing for all versions of HTML, so that's taken care of 
too.

> etc

etc like what?

> and I think HTTP needs its own idea of what is allowed in a HTTP header.

Sure, but that's unrelated to text/*.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>From [email-masked]  Wed Jan 16 03:23:13 2008
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Wed Jan 16 03:23:06 2008
Subject: Unknown text/* subtypes
References: <[email-masked]>
	<[email-masked]><[email-masked]>
	<6.0.0.20.2.20071226102314.083e2170@localhost>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Ian Hickson wrote:
 
>> pre-HTML 4
 
> HTML5 defines processing for all versions of HTML, so that's
> taken care of too.

If you are talking about HTML5 and I'm talking about HTTPbis
we could end up in confusion - I've removed w3-archive@ from
the Cc:, the http-wg list is already archived @ W3C.

>> etc
> etc like what?

See subject, IANA has a registry of known text/* subtypes.

In theory I could start text/x-rexx if I feel that it helps
to display *.cmd REXX programs with IE6.  Some of them are
pc-multilingual-850+euro, I actually put this info in links
to these files.  I don't bother to mention ASCII.  None of
these files is Latin-1, for backwards compatibility (with
among others Netscape 3.*) I use windows-1252, explicitly.

>> I think HTTP needs its own idea of what is allowed in a
>> HTTP header.
> Sure, but that's unrelated to text/*.

Yes, it's related to the Latin-1 default in the "old" HTTP.

 Frank

From: eric at w3.org (Eric Prud'hommeaux)
Date: Fri Jan  4 14:50:10 2008
Subject: [RESEND] Media types for RDF languages N3 and Turtle
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

BCc'ing 
        "Sean B. Palmer" <[email-masked]>, Tim Berners-Lee <[email-masked]>,
	"Daniel W. Connolly" <[email-masked]>,
	Dave Beckett <[email-masked]>,
	Lee Feigenbaum <[email-masked]>,
	Garret Wilson <[email-masked]>,
	Graham Klyne <[email-masked]>, Dan Brickley <[email-masked]>,
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

([email-masked])
Feel free to forward this message to any list for any purpose other than
email address distribution.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 481 bytes
Desc: Digital signature
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20080104/5649a288/attachment.bin
>From [email-masked]  Fri Jan  4 17:33:36 2008
From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri Jan  4 17:33:47 2008
Subject: Unknown text/* subtypes
In-Reply-To: <6.0.0.20.2.20071226102314.083e2170@localhost>
References: <[email-masked]> <[email-masked]>
	<[email-masked]>
	<6.0.0.20.2.20071226102314.083e2170@localhost>
Message-ID: <[email-masked]>

Martin Duerst wrote:
> At 00:45 07/12/19, Frank Ellermann wrote:
>> Julian Reschke wrote:
>>
>>> there's also RFC2616
>> Yes, that's an ugly legacy exception...  
>>
>>> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i20>
>> ...maybe 2616bis can drop this oddity in favour of a simple
>> "unknown text is ASCII" rule.
> 
> The new version of the HTTP spec, 2616bis, should definitely
> drop the iso-8859-1 default, but NOT in favor of "unknown text is ASCII".
> It should just say that there is no default.

As far as I understand, we currently have RFC2046, RFC2616 and RFC3023 
making conflicting requirements:

RFC2046: the default for text/* is US-ASCII 
(<http://tools.ietf.org/html/rfc2046#section-4.1.2>)

RFC2616: the default for text/* received over HTTP is ISO8859-1 
(<http://tools.ietf.org/html/rfc2616#section-3.7.1>)

RFC3023: the default for text/xml is US-ASCII, even when received over 
HTTP (<http://tools.ietf.org/html/rfc3023#section-3.1>)

This is a mess, and as far as I can tell, it would be good if at least 
HTTP would get out of it.

So it seems that we need to decide on two separate questions:

1) Do we want HTTP to override RFC2046's defaults at all?

2) If we do want to continue that, what do we want to mandate?

Right now, browsers (just tested Opera/Safari/Mozilla/IE7) ignore all 
three RFCs for at least text/xml (they all look at the content).

If our answer to 1) is "no", the content will still be broken, but at 
least it's not HTTP's fault anymore.

Otherwise we can state "in absence of charset parameter recipient MAY do 
charset sniffing (BOM, XML decl, HTML meta tag, ...), which would 
probably match what's actually implemented.

> There is a big difference between these two, especially
> for document formats that contain internal 'charset' information.
> A default of US-ASCII makes document-internal 'charset' information
> useless (because the external information wins). No default means
> that the recipient will look at the internal information.

Yep.

>> HTTP oddities shouldn't affect
>> MIME registrations, there's no string "2616" in BCP13.
> 
> One reason for the problems with text/xml was that the
> original MIME default of US-ASCII was enforced. This made
> it impossible to serve XML documents with internal 'charset'
> information only as text/xml.

Hmm. So why did RFC3023 then mandate US-ASCII again? In general, is it 
acceptable *at all* to override charset defaults defined in RFC2046?

BR, Julian

From: harald at alvestrand.no (Harald Alvestrand)
Date: Mon Jan 21 11:35:40 2008
Subject: Request for review of EAI MIME types
Message-ID: <[email-masked]>

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

From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Mon Jan 28 20:45:20 2008
Subject: Request for review of InkML media type: application/inkml+xml
References: <[email-masked]>
Message-ID: <[email-masked]>

Kazuyuki Ashimura wrote:

> the security issues of RFC1738, section 6, should be considered.

Please s/RFC1738, section 6/RFC3986, section 7/ if you have no
special reasons to use the almost completely obsolete RFC 1738.

> Published specification:
> -------------------------
> 
> This media type registration is for InkML documents as described
> by this specification.

IMO you need a reference for "this" specification, IANA publishes
only your registration template, where "this" would make no sense.

 Frank

From: ashimura at w3.org (Kazuyuki Ashimura)
Date: Mon Jan 28 20:10:41 2008
Subject: Request for review of InkML media type: application/inkml+xml
Message-ID: <[email-masked]>

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: [email-masked]
voice: +81.466.49.1170 / fax: +81.466.49.1171

From: ashimura at w3.org (Kazuyuki Ashimura)
Date: Mon Jan 28 20:10:42 2008
Subject: [resent] Request for review of EMMA media type: application/emma+xml
Message-ID: <[email-masked]>

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, <[email-masked]>.

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: [email-masked]
voice: +81.466.49.1170 / fax: +81.466.49.1171

From: distobj at acm.org (Mark Baker)
Date: Thu Jan 24 21:13:21 2008
Subject: Request for review of EAI MIME types
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

I'm no subject matter expert in this space, but everything looks in
order from a registration process POV.  The security considerations
sections weren't included in your message, but are found in the
drafts, and they appear fine.

Mark.

From: harald at alvestrand.no (Harald Alvestrand)
Date: Mon Jan 21 11:35:40 2008
Subject: Request for review of EAI MIME types
Message-ID: <[email-masked]>

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

From: eric at w3.org (Eric Prud'hommeaux)
Date: Fri Jan 18 01:14:28 2008
Subject: Unknown text/* subtypes
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 481 bytes
Desc: Digital signature
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20080117/c56a6d37/attachment.bin

From: eric at w3.org (Eric Prud'hommeaux)
Date: Fri Jan 18 00:49:54 2008
Subject: Unknown text/* subtypes
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

* Ned Freed <[email-masked]> [2008-01-13 16:26-0800]
> > * Ian Hickson <[email-masked]> [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.
> 
> You might, and I emphasize might, be able to get this changed to protocol
> specific restriction. (The MIME specifications specify both an email-specific
> extension as well as some more generally useful facilities.) There is no chance
> of this rule being lifted in general.
> 
> > ? 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)?
> 
> Not only does email depend on this, conformance to this has been dramatically
> strengthened, not weakened, in subsequest revisions of the email protocol
> specification. Specifically, RFC 821 was essentially silent on what bare CR and
> LF mean, but 2821 and 2821bis (now in last call) both say that bare CR and LF
> MUST NOT be sent and if received MUST NOT be treated as CRLF.

I guess we can measure compliance by what causes the clients to wrap
lines. Attached is a set of documents in different encodings, each
served with text/x-unknown and no charset. I expet this is a violation
of 2046, but I wanted to see what clients actually do.

These documents are also available on the web:

http://www.w3.org/2008/01/text/CRLF.txu		    CRs and LFs
http://www.w3.org/2008/01/text/latin-1-diac.txu	    d???r?t?c?ls in latin-1
http://www.w3.org/2008/01/text/utf-8-diac.txu	    d???r?t?c?ls in utf-8
http://www.w3.org/2008/01/text/utf-8-cyrillic.txu   ???????? in utf-8
http://www.w3.org/2008/01/text/utf-8-kanji.txu	    ?? in utf-8
http://www.w3.org/2008/01/text/shift-jis-kanji.txu  ?? in shift_jis

and their behavior in various web clients is documented at
  http://esw.w3.org/topic/ConformanceNotes

> This, incidentially, is not the way I personally think things should have been
> done. I like the "ignore bare CR treat LF like CRLF" approach. But my personal
> opinion isn't especially relevant - I mention it only to avoid "shoot the
> messenger" sorts of responses.
> 
> > I would like to think that MIME
> > shouldn't care about recognizing new lines in the text block.
> 
> I'm sorry, but that's fanciful in the extreme.

Let me try provide a concrete argument against my proposal:

"Mail, News and HTTP clients all need to render text/ stuff on the
screen, and a shared understanding of CRLF is essential to the user
experience."

> > 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
> 
> Again, I personally think this is the way to go. But that's not what
> has happened.

It's not what happened spec-wise, but I'm using this to see what happened
in the implementations.

> > 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
> > ]]
> 
> Again, there is absolutely no chance this will fly for email so it cannot be 
> written with this degree of generality. And if this is made protocol specific
> the specifics of any protocol other than email don't belong in a RFC 2046
> revision.

fair point. HTTP1.1bis folks may want to consider this.

> > @@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.
> 
> Marking something as utf-8 when it is in fact restricted to the us-ascii subset
> has been known to cause problems. I think change in this area is unlikely.

tx for your thoughts and attention on this.

> 				Ned

@@is a "no-change revision" is changing things if it
documents current practice contrary to the old spec.
-- 
-eric

office: +1.617.258.5741 32-G528, MIT, Cambridge, MA 02144 USA
mobile: +1.617.599.3509

([email-masked])
Feel free to forward this message to any list for any purpose other than
email address distribution.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 481 bytes
Desc: Digital signature
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20080117/9b338835/attachment.bin

From: LMM at acm.org (Larry Masinter)
Date: Thu Jan 17 20:03:57 2008
Subject: Unknown text/* subtypes
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]><[email-masked]>	<6.0.0.20.2.20071226102314.083e2170@localhost>	<[email-masked]> <[email-masked]>
Message-ID: <001b01c8593a$d36de8f0$7a49bad0$@org>

(bcc: http-wg because this is about the ietf-types proposal for RDF types)

I think it would be good to separate out the discussion of HTTP & browser
behavior from the MIME registrations of RDF representations. 

The simple solution for Media Types for RDF languages is -- if you really
want to use text/*, then always use a charset parameter, even if you'd
rather not. 

Don't try to change MIME behavior or update the default or otherwise mess
with it. You can say, using current MIME, what you want to say. Perhaps the
default to US-ASCII is annoying, the content-type string is longer than you
would like, but changing MIME is unnecessary.

Secondly, don't use use the '+' syntax, as in: text/rdf+n3, text/rdf+turtle
since it doesn't fit into the paradigm established for +xml; this was noted
during the discussion of registration of +zip types.

For an alternative, I imagine there are lots of possibilities. Personally, I
prefer being more explicit, e.g.,

Label N3 documents as:
     text/w3c.rdf.n3;charset=utf-8

label Turtle files as:
     text/w3c.rdf.turtle;charset=utf-8

Larry

From: justivo at gmail.com (=?UTF-8?Q?Ivo_Emanuel_Gon=C3=A7alves?=)
Date: Wed Jan 16 05:36:31 2008
Subject: Request for review of Ogg Media Types: video/ogg, audio/ogg, application/ogg
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 1/15/08, Magnus Westerlund <[email-masked]> wrote:
> I am willing to become the sponsoring AD for this document. Please
> submit an updated internet draft and then notify me personally when you
> are satisfied with the draft and think it is ready to be published.

Thank you.  I will do so.

Regards,
Ivo

From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Wed Jan 16 03:23:06 2008
Subject: Unknown text/* subtypes
References: <[email-masked]> <[email-masked]><[email-masked]> <6.0.0.20.2.20071226102314.083e2170@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Ian Hickson wrote:
 
>> pre-HTML 4
 
> HTML5 defines processing for all versions of HTML, so that's
> taken care of too.

If you are talking about HTML5 and I'm talking about HTTPbis
we could end up in confusion - I've removed w3-archive@ from
the Cc:, the http-wg list is already archived @ W3C.

>> etc
> etc like what?

See subject, IANA has a registry of known text/* subtypes.

In theory I could start text/x-rexx if I feel that it helps
to display *.cmd REXX programs with IE6.  Some of them are
pc-multilingual-850+euro, I actually put this info in links
to these files.  I don't bother to mention ASCII.  None of
these files is Latin-1, for backwards compatibility (with
among others Netscape 3.*) I use windows-1252, explicitly.

>> I think HTTP needs its own idea of what is allowed in a
>> HTTP header.
> Sure, but that's unrelated to text/*.

Yes, it's related to the Latin-1 default in the "old" HTTP.

 Frank

From: magnus.westerlund at ericsson.com (Magnus Westerlund)
Date: Tue Jan 15 11:24:36 2008
Subject: Request for review of Ogg Media Types: video/ogg, audio/ogg, application/ogg
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Ivo Emanuel Gon?alves skrev:
> Hello Simon,
> 
> On 1/14/08, Simon Josefsson <[email-masked]> wrote:
>> There is a reference for base64 to RFC2397 which
>> looks odd to me, please consider to use RFC4648 instead.
> 
> You are right.
> 
> I wonder: is there a way to make this minor change without resetting
> the time counter?  It would be nice if it would not necessary to wait
> one more month until the media types are accepted by IANA.  Or maybe
> IANA does not need to wait until the I-D becomes accepted as an RFC?
> 

The timer for the IETF types list review is not normally reset for minor 
corrections. Only substantial or controversial ones really need a 
reissued review period. There will also be time at the IETF last call to 
make a second review.

However, I get the impression that you misunderstand how and when the 
update will happen. As this media type is in the standard tree and was 
registered by an IETF standards track document, the only way of updating 
it is to publish an RFC that obsoletes the previous one. Thus your 
updated document needs to get AD sponsored and be approved by the IESG 
before the update can happen. After the approval IANA will update the 
media types registry to point at the new RFC.

I am willing to become the sponsoring AD for this document. Please 
submit an updated internet draft and then notify me personally when you 
are satisfied with the draft and think it is ready to be published.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

From: ian at hixie.ch (Ian Hickson)
Date: Tue Jan 15 16:37:33 2008
Subject: Unknown text/* subtypes
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]><[email-masked]> <6.0.0.20.2.20071226102314.083e2170@localhost> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Tue, 15 Jan 2008, Frank Ellermann wrote:
> >
> > For example HTML4 says to not default to any encoding at all [1]
> [...]
> 
> Yes, but HTTP has to work for plain text

RFC 2046 handles that.

> pre-HTML 4

HTML5 defines processing for all versions of HTML, so that's taken care of 
too.

> etc

etc like what?

> and I think HTTP needs its own idea of what is allowed in a HTTP header.

Sure, but that's unrelated to text/*.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue Jan 15 05:05:07 2008
Subject: Request for review of Ogg Media Types: video/ogg, audio/ogg, application/ogg
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Ivo Emanuel Gon?alves wrote:
> Hello Simon,
> 
> On 1/14/08, Simon Josefsson <[email-masked]> wrote:
>> There is a reference for base64 to RFC2397 which
>> looks odd to me, please consider to use RFC4648 instead.
> 
> You are right.
> 
> I wonder: is there a way to make this minor change without resetting
> the time counter?  It would be nice if it would not necessary to wait
> one more month until the media types are accepted by IANA.  Or maybe
> IANA does not need to wait until the I-D becomes accepted as an RFC?

That kind of correction should happen during AUTH48. No need to reset 
any counters.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20080114/8e409b28/smime.bin

From: justivo at gmail.com (=?UTF-8?Q?Ivo_Emanuel_Gon=C3=A7alves?=)
Date: Tue Jan 15 04:15:52 2008
Subject: Request for review of Ogg Media Types: video/ogg, audio/ogg, application/ogg
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hello Simon,

On 1/14/08, Simon Josefsson <[email-masked]> wrote:
> There is a reference for base64 to RFC2397 which
>looks odd to me, please consider to use RFC4648 instead.

You are right.

I wonder: is there a way to make this minor change without resetting
the time counter?  It would be nice if it would not necessary to wait
one more month until the media types are accepted by IANA.  Or maybe
IANA does not need to wait until the I-D becomes accepted as an RFC?

> Thanks for including the liberal 'Copying Conditions' section, which
> makes it possible to include the document in free software packages.

Thank you for the appreciation.

Regards,
Ivo

From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Tue Jan 15 04:12:29 2008
Subject: Unknown text/* subtypes
References: <[email-masked]> <[email-masked]><[email-masked]> <6.0.0.20.2.20071226102314.083e2170@localhost> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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

From: simon at josefsson.org (Simon Josefsson)
Date: Mon Jan 14 14:34:15 2008
Subject: Request for review of Ogg Media Types: video/ogg, audio/ogg, application/ogg
In-Reply-To: <[email-masked]> ("Ivo Emanuel =?iso-8859-1?Q?Gon=E7alves=22's?= message of "Mon, 14 Jan 2008 12:53:33 +0000")
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

"Ivo Emanuel Gon?alves" <[email-masked]> writes:

> Hello list,
>
> This is the continuation to a thread started by me roughly a month
> ago.  As a reminder, anyone may still post feedback regarding the Ogg
> media types described in [1].  Feedback regarding good and bad aspects
> is equally welcome.

I read the draft, and it looks fine to me.  There is a reference for
base64 to RFC2397 which looks odd to me, please consider to use RFC4648
instead.

Thanks for including the liberal 'Copying Conditions' section, which
makes it possible to include the document in free software packages.

Thanks,
Simon

From: justivo at gmail.com (=?UTF-8?Q?Ivo_Emanuel_Gon=C3=A7alves?=)
Date: Mon Jan 14 14:18:53 2008
Subject: Request for review of Ogg Media Types: video/ogg, audio/ogg, application/ogg
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hello list,

This is the continuation to a thread started by me roughly a month
ago.  As a reminder, anyone may still post feedback regarding the Ogg
media types described in [1].  Feedback regarding good and bad aspects
is equally welcome.

So far, only Mr Ellermann commented on the registration proposal.
Please don't feel shy.

-Ivo

[1] http://www.ietf.org/internet-drafts/draft-goncalves-rfc3534bis-00.txt

From: ned.freed at mrochek.com (Ned Freed)
Date: Mon Jan 14 01:44:11 2008
Subject: Unknown text/* subtypes
In-Reply-To: "Your message dated Sun, 13 Jan 2008 13:40:12 -0500" <[email-masked]>
Message-ID: <[email-masked]>

> * Ian Hickson <[email-masked]> [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.

You might, and I emphasize might, be able to get this changed to protocol
specific restriction. (The MIME specifications specify both an email-specific
extension as well as some more generally useful facilities.) There is no chance
of this rule being lifted in general.

> ? 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)?

Not only does email depend on this, conformance to this has been dramatically
strengthened, not weakened, in subsequest revisions of the email protocol
specification. Specifically, RFC 821 was essentially silent on what bare CR and
LF mean, but 2821 and 2821bis (now in last call) both say that bare CR and LF
MUST NOT be sent and if received MUST NOT be treated as CRLF.

This, incidentially, is not the way I personally think things should have been
done. I like the "ignore bare CR treat LF like CRLF" approach. But my personal
opinion isn't especially relevant - I mention it only to avoid "shoot the
messenger" sorts of responses.

> I would like to think that MIME
> shouldn't care about recognizing new lines in the text block.

I'm sorry, but that's fanciful in the extreme.

> 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

Again, I personally think this is the way to go. But that's not what
has happened.

> 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
> ]]

Again, there is absolutely no chance this will fly for email so it cannot be 
written with this degree of generality. And if this is made protocol specific
the specifics of any protocol other than email don't belong in a RFC 2046
revision.

> @@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.

Marking something as utf-8 when it is in fact restricted to the us-ascii subset
has been known to cause problems. I think change in this area is unlikely.

				Ned

From: eric at w3.org (Eric Prud'hommeaux)
Date: Sun Jan 13 19:41:08 2008
Subject: Unknown text/* subtypes
In-Reply-To: <[email-masked]>
References: <[email-masked]> <6.0.0.20.2.20071226102314.083e2170@localhost> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

* Ian Hickson <[email-masked]> [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.html#determining
> 
> 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

([email-masked])
Feel free to forward this message to any list for any purpose other than
email address distribution.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 481 bytes
Desc: Digital signature
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20080113/96f92a01/attachment.bin

From: ian at hixie.ch (Ian Hickson)
Date: Tue Jan 15 16:37:32 2008
Subject: Unknown text/* subtypes
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]><[email-masked]> <6.0.0.20.2.20071226102314.083e2170@localhost> <[email-masked]>
Message-ID: <[email-masked]>

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.

-- 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.html#determining

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri Jan  4 17:33:47 2008
Subject: Unknown text/* subtypes
In-Reply-To: <6.0.0.20.2.20071226102314.083e2170@localhost>
References: <[email-masked]> <[email-masked]> <[email-masked]> <6.0.0.20.2.20071226102314.083e2170@localhost>
Message-ID: <[email-masked]>

Martin Duerst wrote:
> At 00:45 07/12/19, Frank Ellermann wrote:
>> Julian Reschke wrote:
>>
>>> there's also RFC2616
>> Yes, that's an ugly legacy exception...  
>>
>>> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i20>
>> ...maybe 2616bis can drop this oddity in favour of a simple
>> "unknown text is ASCII" rule.
> 
> The new version of the HTTP spec, 2616bis, should definitely
> drop the iso-8859-1 default, but NOT in favor of "unknown text is ASCII".
> It should just say that there is no default.

As far as I understand, we currently have RFC2046, RFC2616 and RFC3023 
making conflicting requirements:

RFC2046: the default for text/* is US-ASCII 
(<http://tools.ietf.org/html/rfc2046#section-4.1.2>)

RFC2616: the default for text/* received over HTTP is ISO8859-1 
(<http://tools.ietf.org/html/rfc2616#section-3.7.1>)

RFC3023: the default for text/xml is US-ASCII, even when received over 
HTTP (<http://tools.ietf.org/html/rfc3023#section-3.1>)

This is a mess, and as far as I can tell, it would be good if at least 
HTTP would get out of it.

So it seems that we need to decide on two separate questions:

1) Do we want HTTP to override RFC2046's defaults at all?

2) If we do want to continue that, what do we want to mandate?

Right now, browsers (just tested Opera/Safari/Mozilla/IE7) ignore all 
three RFCs for at least text/xml (they all look at the content).

If our answer to 1) is "no", the content will still be broken, but at 
least it's not HTTP's fault anymore.

Otherwise we can state "in absence of charset parameter recipient MAY do 
charset sniffing (BOM, XML decl, HTML meta tag, ...), which would 
probably match what's actually implemented.

> There is a big difference between these two, especially
> for document formats that contain internal 'charset' information.
> A default of US-ASCII makes document-internal 'charset' information
> useless (because the external information wins). No default means
> that the recipient will look at the internal information.

Yep.

>> HTTP oddities shouldn't affect
>> MIME registrations, there's no string "2616" in BCP13.
> 
> One reason for the problems with text/xml was that the
> original MIME default of US-ASCII was enforced. This made
> it impossible to serve XML documents with internal 'charset'
> information only as text/xml.

Hmm. So why did RFC3023 then mandate US-ASCII again? In general, is it 
acceptable *at all* to override charset defaults defined in RFC2046?

BR, Julian

From: eric at w3.org (Eric Prud'hommeaux)
Date: Fri Jan  4 14:50:10 2008
Subject: [RESEND] Media types for RDF languages N3 and Turtle
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

BCc'ing 
        "Sean B. Palmer" <[email-masked]>, Tim Berners-Lee <[email-masked]>,
	"Daniel W. Connolly" <[email-masked]>,
	Dave Beckett <[email-masked]>,
	Lee Feigenbaum <[email-masked]>,
	Garret Wilson <[email-masked]>,
	Graham Klyne <[email-masked]>, Dan Brickley <[email-masked]>,
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

([email-masked])
Feel free to forward this message to any list for any purpose other than
email address distribution.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 481 bytes
Desc: Digital signature
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20080104/5649a288/attachment.bin