- From: Graham Klyne <graham.klyne@zoo.ox.ac.uk>
- Date: Thu, 12 Jul 2012 17:59:39 +0100
- To: Luc Moreau <l.moreau@ecs.soton.ac.uk>
- CC: W3C provenance WG <public-prov-wg@w3.org>
luc, Just to confirm what I said in today's teleconference: yes that is what I am recommending. "charset — this parameter is mandatory. The value of charset is always UTF-8." (Except I suppose the "optional" in the "optional parameters" heading is now a bit odd - I don't offhand recall if that's part of the template.) #g -- On 12/07/2012 15:20, Luc Moreau wrote: > Hi Graham, > > For the avoidance of doubt, are you recommending we change the current text: > > Optional parameters: > charset — this parameter is required when transferring non-ASCII data. If > present, the value of charset is always UTF-8. > > into > > > Optional parameters: > charset — this parameter is mandatory. The value of charset is always UTF-8. > > > Thanks, > Luc > > On 07/12/2012 02:06 PM, Graham Klyne wrote: >> >> >> -------- Original Message -------- >> Subject: Re: [apps-discuss] RFC 6657 on Update to MIME regarding "charset" >> Parameter Handling in Textual Media Types >> Date: Tue, 10 Jul 2012 22:44:54 -0700 (PDT) >> From: Ned Freed <ned.freed@mrochek.com> >> To: Graham Klyne <Graham.Klyne@zoo.ox.ac.uk> >> >>> On 10/07/2012 18:18, Ned Freed wrote: >>> > Does this type actually meet the criteria for text specified in RFC 2046 >>> > section 4.1? I rather suspect it doesn't. If not, it really has no business >>> > being a text subtype, and all of this is moot. >> >>> I believe it does. We're not talking XML or anything like that. It's a textual >>> notation for provenance information, intended for human and occasional machine >>> consumption. >> >> Then my suggestion would be to make the charset parameter mandatory, with >> the only legal value being utf-8. The alternative would be to omit >> it and specify utf-8 as the default, but as I said, that's not likely >> to interoperate well. >> >> Ned >> >> >
Received on Thursday, 12 July 2012 17:25:07 UTC