I think the underlying issue we've all had with specifying XRI syntax in terms of unicode characters (rather than US-ASCII characters) is that there is a lot of infrastructure already deployed (based on a number of specificaitons like RFC 2396 and the HTTP specification for example) that deal only with 8-bit US-ASCII characters.
The point of IRI was to be able to define syntaxes for identifiers using unicode characters and then have those unicode strings automatically be converted (through IRI-defined transformations) into the URI-legal (a subset of US-ASCII) characters that comprise URIs.
When talking about resolution, I *really* need to be able to assume that all characters being resolved are URI-legal (or escapable into URI-legal characters) because underlying network protocols assume US-ascii character sets. And even when talking about *presenting* (as opposed to resolving) XRIs) US-ASCII or URI-legal is the only set of characters that are legal in many environments.
The Question:
Are you merely suggesting that we define XRIs across the scope of unicode characters, and then define a transform to URI-legal characters for the purpose of use of the XRI in places where URIs are expected? That sounds like it may be a reasonable approach - it may not even affect resolution (if we simply require that the transformation to URI-legal characters occurs before resolution).
Thanks for your patience in explaining this to us..
-Gabe
> -----Original Message-----
> From: Sakimura, Nat [mailto:]
> Sent: Friday, July 04, 2003 12:20 AM
> To: Wachob, Gabe; Drummond Reed; Dave McAlpin;
>
> Subject: RE: [xri-editors] RE: Closure on I18N approach (was RE:
> [xri-edit ors] Status on draft spec)
>
>
> IMHO XRI should be internationalized from the beginning.
> Introducing XRI
> and IXRI will create unnecessary confusion and uncleanness in the
> implementation as well as no adaptation in the reality. We
> should design
> the system UTF-8 clean, and %escaping of non-ascii characters should
> happen only as the last resort.
>
> Is there any problem in making the following range as unreserved as
> well?
>
> ucschar = %xA0-D7FF / %xF900-FDCF / %xFDF0-FFEF /
> / %x10000-1FFFD / %x20000-2FFFD / %x30000-3FFFD
> / %x40000-4FFFD / %x50000-5FFFD / %x60000-6FFFD
> / %x70000-7FFFD / %x80000-8FFFD / %x90000-9FFFD
> / %xA0000-AFFFD / %xB0000-BFFFD / %xC0000-CFFFD
> / %xD0000-DFFFD / %xE1000-EFFFD
>
> Doing this will impact the structure of the document a little that
> perhaps we have to make a section in I18N chapter about the UTF-8 to
> ASCII translation.
>
> Nat
>
> -----Original Message-----
> From: Wachob, Gabe [mailto:]
> Sent: Friday, July 04, 2003 10:27 AM
> To: Sakimura, Nat; Drummond Reed; Wachob, Gabe; Dave McAlpin;
>
> Subject: RE: [xri-editors] RE: Closure on I18N approach (was RE:
> [xri-edit ors] Status on draft spec)
>
> Perhaps the approach should be that the stuff currently there is the
> "correctness rules" after a unicode -> US-Ascii
> transformation has been
> performed. Any string that ends up as a legal XRI (in the 2396
> definition we have now) after this transformation is thus a legal IXRI
> (internationalized XRI).
>
> Does that approach make sense?
>
> Thanks for guiding us on this Nat - I think we'd be hopelessly lost if
> we didn't have you on board here.
>
> -Gabe
>
> > -----Original Message-----
> > From: Sakimura, Nat [mailto:]
> > Sent: Thursday, July 03, 2003 6:21 PM
> > To: Drummond Reed; Wachob, Gabe; Dave McAlpin;
> >
> > Subject: [xri-editors] RE: Closure on I18N approach (was RE:
> > [xri-editors] Status on draft spec)
> >
> >
> > I am basically with it. My point was just that in the last
> edition, it
> > was stated that character set and thus reserved and
> > unreserved character
> > set will basically come from RFC2396. I think it should
> come from IRI
> > instead (for obvious reason).
> >
> > I am going to work on the section today.
> >
> > Nat
> >
> > -----Original Message-----
> > From: Drummond Reed [mailto:]
> > Sent: Friday, July 04, 2003 2:46 AM
> > To: Wachob, Gabe; Sakimura, Nat; Dave McAlpin;
> >
> > Subject: Closure on I18N approach (was RE: [xri-editors]
> > Status on draft
> > spec)
> >
> > Nat,
> >
> > First, +1 on Gabe's reply (glad I read it before I typed my own).
> >
> > Second, glad you are back from your trip. From a process standpoint,
> > with Gabe's submission of the resolution portion of the spec, which
> > DaveM is incorporating into the main body of the doc today,
> > the Encoding
> > and I18N sections remain the last to be filled in.
> >
> > Which means closing on our overall approach to this issue
> is the next
> > major decision at hand.
> >
> > Third, to reinforce one point that DaveM and I have been
> dealing with
> > extensively with regard to RFC 2396bis: any IETF spec that is at
> > Internet Draft status can't be referenced normatively by
> the XRI spec.
> > That's the case with 2396bis, and it's also the case with
> > IRI. So if we
> > want to use the IRI approach, we'd have to, as Gabe says,
> incorporate
> > its substantive content directly.
> >
> > What do you suggest is the best approach?
> >
> > =Drummond
> >
> >
> > -----Original Message-----
> > From: Wachob, Gabe [mailto:]
> > Sent: Thursday, July 03, 2003 9:58 AM
> > To: 'Sakimura, Nat'; Dave McAlpin;
> > Subject: RE: [xri-editors] Status on draft spec
> >
> > Nat
> > I'm not sure I see the distinction you are making.
> >
> > I think we define the XRI syntax in terms of 2396 but then
> > define a set of IRI-like transformation rules from scripts
> > and character
> > sets other than US-ASCII (actually the more limited set of URI-legal
> > characters). In other words, do exactly what the IRI draft proposes.
> > Unfortunately, the IRI draft is not a real specification,
> so we cannot
> > cite it normatively, but I would strongly favor adopting
> its approach
> > (even that means lifting sections word for word).
> >
> > For those of us in US-ASCII land, this has little or
> > no effect.
> > For those who have more interesting character sets, this
> > means that yes,
> > user interfaces will have to convert XRI from the
> URI-escaped form to
> > the localized form for the particular user. But in either
> > case the XRIs
> > will be human readable, so long as the client software performs i18n
> > unescaping and translation into local character sets.
> >
> > Is this #2?
> >
> >
> > -Gabe
> >
> > > -----Original Message-----
> > > From: Sakimura, Nat [mailto:]
> > > Sent: Thursday, July 03, 2003 2:59 AM
> > > To: Dave McAlpin;
> > > Subject: RE: [xri-editors] Status on draft spec
> > >
> > >
> > > Sorry for the delay. I am finally back from two weeks
> > > consecutive trips.
> > >
> > >
> > > Looking at the discussion, it looks like we base most syntax
> > > on RFC2396.
> > > This would assume/implies the following:
> > >
> > > 1) Most international XRI will not be human readable.
> > > Or
> > > 2) We are talking about the URI escape form of XRI for
> machine level
> > > handling, which a user will not see because the XRI client
> > > software will
> > > take care of the conversion.
> > >
> > > Which is true?
> > >
> > > My inclination is towards 2) by the way. 1) will not fulfill
> > > our promise
> > > of human readability. This will in turn have impact on the
> > > section 2.1.
> > > Instead of RFC 2396, we probably need to be basing it on IRI.
> > >
> > > Nat Sakimura
> > >
> > > -----Original Message-----
> > > From: Dave McAlpin [mailto:]
> > > Sent: Thursday, July 03, 2003 4:04 AM
> > > To:
> > > Subject: [xri-editors] Status on draft spec
> > >
> > > The following sections of the draft spec are currently waiting for
> > > input.
> > >
> > > Section 2.3 Character Encoding and Internationalization
> > (Gabe and Nat)
> > > Section 2.5.3 Internationalized XRI Equivalence (Gabe and Nat)
> > > Section 3 Resolution (Gabe, Mike and Peter)
> > >
> > > I'm doing a pass through the doc and making editorial changes
> > > right now.
> > > I'll post a new version (04) this afternoon so people can
> > see how it's
> > > shaping up and to see how missing sections will fit into
> > the doc as a
> > > whole.
> > >
> > > Dave
> > >
> > >
> > >
> > >
> >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
>
> > > For additional commands, e-mail:
> >
> > >
> > >
> >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
>
> > > For additional commands, e-mail:
> >
> > >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > For additional commands, e-mail:
>
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > For additional commands, e-mail:
>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
>
