W3C home > Mailing lists > Public > www-tag@w3.org > March 2004

RE: Reviewed charmod fundamentals

From: Misha Wolf <Misha.Wolf@reuters.com>
Date: Mon, 08 Mar 2004 12:40:21 +0000
Message-ID: <T6836e1c003c407b71045c@dtcseuvig4.dtc.lon.ime.reuters.com>
To: Jon Hanna <jon@hackcraft.net>
Cc: Julian Reschke <julian.reschke@gmx.de>, Elliotte Rusty Harold <elharo@metalab.unc.edu>, Tim Bray <tbray@textuality.com>, www-tag@w3.org

The sentence quoted by Tim says:

   C016 [S] When designing a new protocol, format or API, 
   specifications SHOULD mandate a unique character encoding.

Note the "SHOULD", which is used in line with RFC 2119.

If you are designing a protocol which would benefit from 
allowing multiple encodings, you are free to design them in.


-----Original Message-----
From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] On Behalf
Of Jon Hanna
Sent: 08 March 2004 12:29
To: Misha Wolf
Cc: Julian Reschke; Elliotte Rusty Harold; Tim Bray; www-tag@w3.org
Subject: RE: Reviewed charmod fundamentals

Quoting Misha Wolf <Misha.Wolf@reuters.com>:

> You are assuming that protocols carry documents.  Lots of 
> protocols carry small discrete snippets of text in separate 
> 'fields'.  In such cases, there seems no point in allowing 
> multiple encodings.

I'm assuming that there are one or more protocols that do carry
documents, and
hence would benefit from allowing both UTF-8 and UTF-16.

Jon Hanna
"...it has been truly said that hackers have even more words for
equipment failures than Yiddish has for obnoxious people." - jargon.txt

--------------------------------------------------------------- -
        Visit our Internet site at http://www.reuters.com

Get closer to the financial markets with Reuters Messaging - for more
information and to register, visit http://www.reuters.com/messaging

Any views expressed in this message are those of  the  individual
sender,  except  where  the sender specifically states them to be
the views of Reuters Ltd.
Received on Monday, 8 March 2004 07:40:29 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:41 UTC