Subject: Re: RFC: UTF-8 iCalendar bug solution

From: [email-masked]
Date: Mon, 24 Feb 2003 18:07:50 -0500

Chris, excuse my ignorance if I say something stupid but here goes.  One of
the missions of all working groups is to ensure that our drafts/RFC's live
well in the world of internationalization.  I believe Unicode is one of
those areas.  We "sort of " reviewed our drafts a year ago and said we felt
they were "OK".  Do you feel that is the case - it sounds like you might
have an idea - and I'm taking the liberty to check for a level-set.  If you
think we're OK, let us know.  If you think this is a problem, can you let
us know what we need to do to make sure our RFC's handle unicode, etc.

                      "Chris Olds"                                                                                                         
                      <[email-masked]        To:       <[email-masked]>                                                       
                      >                            cc:                                                                                     
                      Sent by:                     Subject:  Re: RFC: UTF-8 iCalendar bug solution                                         
                      owner-ietf-calendar@m                                                                                                
                      ail.imc.org                                                                                                          

                      02/24/03 04:47 PM                                                                                                    

On Mon, 24 Feb 2003 16:11:22 -0500, Mark Swanson wrote
> Thanks Chris (and to everyone else for responding).

Glad I can help (I'm new here, but I learned a lot about UCS/UTF working on
XML WGs).

> I haven't found documentation that 0xf9-0xff is not allowed, but I
> have found in the link Chris provided and in RFC 2779:
>
> - -  The octet values FE and FF never appear.
>
> Is there a specific reason the other 5 bytes do not appear?
>
> I see the start octet that states the following bytes are to encode:
> 0400 0000-7FFF FFFF (UCS-4)
> starts with UTF-8 (1111110x) (0xFC).
>
> If we do not allow 0xFC we will not allow a very large mapping of
> UCS-4 characters from 0400 0000-7FFF FFFF.

This is true, but not (currently) that big a deal.  Most importantly,
Unicode
3.1 (the current version) doesn't define any characters from 0x20000 up
(the
jargon is that only the BMP (Basic Multilingual Plane) and the 1st Astral
Plane (0x10000-0x1FFFF) are defined).  For these planes, a lead byte of
11110xxx (0xF0-0xF7) is (more than) enough (in fact, it will encode 21 bits
of
data, covering the BMP and the first 31 astral planes).  Since a lead byte
of
0xF8 (111110 00) allows 24 bits worth of characters to be encoded, I cannot
imagine a need for greater range anytime soon.

    /cco

--
GPG Key Fingerprint: B375 A4E7 752B DB8C 4359  852E C3CF BF64 379A E9B2
Debian Project (http://www.debian.org)

---

From: "Chris Olds" <[email-masked]>
Date: Mon, 24 Feb 2003 15:42:31 -0800

On Mon, 24 Feb 2003 18:07:50 -0500, pregen wrote
> Chris, excuse my ignorance if I say something stupid but here goes.  
> One of the missions of all working groups is to ensure that our 
> drafts/RFC's live well in the world of internationalization.  I 
> believe Unicode is one of those areas.  We "sort of " reviewed our 
> drafts a year ago and said we felt they were "OK".  Do you feel that 
> is the case - it sounds like you might have an idea - and I'm taking 
> the liberty to check for a level-set.  If you think we're OK, let us 
> know.  If you think this is a problem, can you let us know what we 
> need to do to make sure our RFC's handle unicode, etc.

As I said, I'm new here; I started writing an rfc2445 parser last week (in
Python; I know there are parsers in other languages, but since I wanted to
understand the RFC anyway, I thought, 'what the heck...').  I haven't actually
sat down and read much beyond 2445, so I can't yet give any opinion on the
recent draft; it's on my list of VTODO's...

In 2445, there appears to be a reliance on MIME encapsulation to carry
encoding (and character set) information, which I'm not completely comfortable
with, but that seems to be the way these things are done in IETF work.  It
certainly isn't very clear to me how the character-range productions that
include NON-US-ASCII are supposed to be used if a MIME-encapsulated iCalendar
object specifies a charset parameter other than UTF-8 (e.g. "text/calendar;
charset=ISO-8859-15"); it appears that a) people mostly Don't Do That, and b)
if they did, the expectation is that applications should behave as they would
if the data was transcoded into UTF-8 and presented.  The problem, of course,
is that I just made that up.

As I said, I still need to read the current CAP draft, but I'll be sure to
give my opinion on i18n either way.

    /cco