[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ltru] Issue 63:



I support replacing ABNF notations as documented by Martin in a previous email on this thread with U+ notation. However I note that the ABNF for record-jar in Section 3.1.1 contains references to Unicode code points in this production:

   CHARS      = (%x21-10FFFF)      ; Unicode code points

I want to know if we can keep this, or, failing that, what we're supposed to change it to. Note that I got this particular production from draft-iri (that would be your draft, Martin :-) ).

Addison 

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.


> -----Original Message-----
> From: ltru-bounces at ietf.org [mailto:ltru-bounces at ietf.org] On
> Behalf Of "Martin J. Dürst"
> Sent: Wednesday, June 10, 2009 3:48 AM
> To: Alexey Melnikov
> Cc: LTRU Working Group
> Subject: Re: [Ltru] Issue 63:
> 
> [technical contributor]
> 
> On 2009/06/10 19:35, Alexey Melnikov wrote:
> > Martin J. Dürst wrote:
> >
> >> [hats on]
> 
> >> The commenter in the Application Area review commented that we
> should
> >> use the U+00xx notation for identifying characters outside of
> ABNF.
> >> The reasons given are that the notation from the ABNF isn't
> intended
> >> for use outside the ABNF, and that it doesn't follow RFC
> 5137/BCP 137.
> >
> > I think the latter argument (BCP 137) is more important, besides
> this
> > would make 4646bis more consistent with other RFCs recently
> published.
> 
> And more consistent with practice at other standards organizations,
> such
> as (of course) the Unicode Consortium and W3C.
> 
> Regards,    Martin.
> 
> --
> #-# Martin J. Dürst, Professor, Aoyama Gakuin University
> #-# http://www.sw.it.aoyama.ac.jp   mailto:duerst at it.aoyama.ac.jp
> _______________________________________________
> Ltru mailing list
> Ltru at ietf.org
> https://www.ietf.org/mailman/listinfo/ltru

Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.