Title: Message
Case
insensitivity is a form of normalization that a large population of
people receive benefit from. If there's a way to provide that benefit
to those people without degrading functionality where it doesn't make sense,
then I think we should do it.
I'd
hate to see case insensitivity for ALPHA characters go away.
=LOREN
-----Original Message-----
From: Dave
McAlpin [mailto:]
Sent: Thursday, September
04, 2003 11:06 AM
To: 'Sakimura, Nat'; 'Wachob, Gabe';
Subject: RE: [xri] Draft -07 feedback from
another Visa person (responses cont'd)
So are we OK with
case-insensitive comparison for ALPHA characters in the authority component,
or should we drop this altogether?
-----Original
Message-----
From: Sakimura,
Nat [mailto:]
Sent: Thursday, September 04, 2003 10:57
AM
To: Dave McAlpin; Wachob,
Gabe;
Subject: RE: [xri] Draft -07 feedback
from another Visa person (responses cont'd)
I do not
think that there is a good way of introducing “case insensitivity” to Unicode
in general.
Case
insensitivity is a form of normalization, which is very problematic for the
international character set. IMHO, only meaningful form of general equivalence
is the bit to bit comparison or the comparison of the resolved result from the
same authority.
Nat
-----Original
Message-----
From: Dave
McAlpin [mailto:]
Sent: Friday, September 05, 2003 2:43
AM
To: 'Wachob, Gabe';
Subject: RE: [xri] Draft -07 feedback
from another Visa person (responses cont'd)
-----Original
Message-----
From: Wachob,
Gabe [mailto:]
Sent: Thursday, August 28, 2003 4:29
PM
To:
''
Subject: RE: [xri] Draft -07 feedback
from another Visa person (responses cont'd)
Outlook
continues to drive me up the wall - this should be the end of my initial
responses to the comments from Terence Spielman.
Responses continue in
this email:
550-551 I didn't get the meaning
of persistent or re-assignable identifiers
out of this
description.
Yes,
this needs beefing up, as the inline comment mentions.
2.2.3.1 Is it allowable to
escape unicode characters? For example, if one
wanted to
express an international XRI in IA5 (ASCII)? In this
case,
the %AB format described in 2.2.3.1 is insufficient to support
the
expanded character width.
I'll
defer this question to our resident unicode & escaping guru, Dave McAlpin.
I think
step 5 in 2.2.3.2 addresses this when we specify “one escaped triplet for each
octet in the UTF-8 encoding of the disallowed character”. Did you have
something else in mind?
694 Does the lack od
idempotency affect semantics or syntax? I would
hope it would
only be syntax.
Again,
this gets deferred to Dave McAlpin.
It
affects semantics. If an XRI is inadvertently escaped twice and unescaped
once, for example, the result might be semantically different than the
original XRI (this depends, of course, on the original XRI). It’s the
essentially the same problem mentioned in section 2.4.2 of 2396, which says
“implementers should be careful not to escape or unescaped the same string
more than once, since unescaping an already unescaped string might lead to
misinterpreting a percent data character as another escaped character, or vice
versa in the case of escaping an already escaped
string.”
2.2.3.3 How about this as
an alternative?
Escape all current escapes
(%s).
Escape all syntactic elements with cross
references (parens).
Escape all
parens.
Dave
McAlpin has thought through the escaping issues quite a bit. We are trying to
track the (as-yet-not-finalized) RFC 2396bis and IRI (internationalized
resource identifiers) specs, and this adds some complexity with the benefit of
aligning with emerging best practices and architectures. I'd leave it to Dave
to explain exactly how he ended up with the escaping procedure we have.
I don’t
understand the second step. Can you give an example of escaping “all syntactic
elements with cross references”?
878-879 Why are XRI authorities
compared in a case-insensitive manner?
Thats a
good question. Not sure, honestly. Dave? Drummond?
Mostly,
I think, to make the comparison rules for XRIAuthority consistent with those
for URIAuthority (as specified by section 6 of 2396). It may be confusing,
though, in that it only applies to characters in the ALPHA production. That’s
fine for URIAuthorities because they only allow characters in the ALPHA
production, but the XRIAuthority can contain international characters. Is your
objection is that it’s odd that ‘e’ and ‘E’ are equivalent, but ‘e’ with an
accent mark is not equivalent to ‘E’ with the same mark? If it is, then I
agree. Is there a good way to specify case-insensitivity for all Unicode
characters?
Section 3 (I still
need to do some reading)
Global:
Has there been any work on
DECODING XRIs? It's not immediately
clear from the ABNF that
decoding is unambiguous.
I
believe the decoding is mechanical and unambigous.
Dave?
In
general, the escaping/unescaping mirrors IRI work, along with one extra step
for escaping () (parentheses). We definitely wanted to make sure the
transformations were reversible.
I think
the question is actually whether the BNF is unambiguous, i.e. does an XRI
exist that could be interpreted in more than one way by the BNF? I’ve done
some work in this area, but I certainly wouldn’t consider the BNF “proven” at
this point.
In addition, aside from
unresolvable references, is it possible
to canonicalize XRIs?
This is a highly desireable feature
(for equivalence, at a
minimum).
We
talked quite a bit about this. The decision was made to be silent on
canonicalization because equivalence is actually unambigious given
the rules stated. Now, that doesn't mean that its at all
obvious.
I do
think giving names to the escaped vs. unescpaed forms of XRI, at
least, would be useful. Canonicalization would then just be
transforming an identifier into one of those forms. We didn't want to mandate
a single canonical form because different environments would need XRIs in
different levels of escaping and it would be unfortunate to require a specific
canonicalization form that would require otherwise-unneeded transformation.
Again,
Dave McAlpin probably has better input on this.
A
canonical representation might be useful for comparison, but it would involve
a formal definition of things like “minimally escaped”, which would be fairly
difficult to nail down. It would also depend on the existence of a canonical
form for URIs used as cross-references. In other words, an XRI wouldn’t have a
canonical form if it contained cross-references that didn’t define a canonical
form.
Note
that equivalence rules are generally problematic. The IRI proposal, for
example, completely dodges the question of equivalence when it says, “There is
no general rule or procedure to decide whether two arbitrary IRIs are
equivalent or not… Each specification or application that uses IRIs has to
decide on the appropriate criterion for IRI equivalence.” 2396bis notes that
even terms like “different” and “equivalent” are fuzzy in the general spec and
ultimately application dependent.
An XRI is not a URI
(because of the expanded syntax). But
is an URI an XRI?
(no, because of different scheme (xri)).
I think it would be nice
to all URIs be valid XRIs.
Well, by
definition, all URIs can't be XRIs because URI's have different schemes -
XRI's must all have the "xri:" scheme. I think the goal of having all
URIs easily and trivially transformable into XRIs (ie remove the scheme and
insert xri:) is laudable, though its unclear that in many cases this makes a
lot of sense. This is because the XRIs are structured and resolution of
the XRIs (at the very least) gives special meaning to the firs segment (the
authority) -- not all URIs are hierarchical or treat the first
"segment" specially. Examples include mailto:, uuid:, cid:
etc
Note
also that it’s trivial to convert any legal URI into an XRI by simply
enclosing it in a cross-reference, e.g. mailto: -> xri:(mailto:), though I don’t know
that that’s generally useful.
Hope
that kicks off the conversation and gives us editors some good
pointers on where we need to focus on cleaning up of
language.
-Gabe
