RE: [xri] Draft -07 feedback from another Visa person (responses cont'd)

["Wachob, Gabe" <gwachob@visa.com>]

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.

 

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.  

 

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.

878-879 Why are XRI authorities compared in a case-insensitive manner? 

Thats a good question. Not sure, honestly. Dave? Drummond?  

 

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.

 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.

 

 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

 

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