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
