OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Possible changes to XRI 1.0


Since we're discussing a non-backward compatible change to the 1.0 spec, I was asked to suggest other changes we might consider at the same time. I'm sure this list is incomplete, so please feel free to add others.
 
-- xri-authority versus 2396bis-style authority
 
The draft of 2396bis on which we relied (draft 3), defined authority in a way that disqualified XRI authorities (@epok or =dave, for example). That's the reason there's no // in an XRI like xri:@epok - // must be followed by a 2396bis-style authority and @epok didn't qualify. This changes in the current draft of 2396bis, where most restrictions on the form of authority have been removed. Since we now have more options, we should probably revisit our original decision.
There are two main problems with making an XRI authority be an authority per 2396bis. First, we currently depend on // to introduce a DNS-based authority, so we'd need to invent some syntax to distinguish between a DNS-based authority and an XRI authority. Second, two important characters are disallowed in the host portion of the authority component (the part we care about) - the at sign ("@") and colon (":"). To be a 2396bis-style authority we'd need new characters for both at and colon.
I'm not necessarily proposing this change, just noting that it's now something that's possible and raising the issue for discussion.
 
-- Resolution of uri-authority based XRIs
 
Section 3.3 defines resolution for XRIs containing a uri-authority, like xri://xri.epok.net/foo. I think there may be a couple of problems with that section. First, it explicitly requires http, implicitly precluding https. Second, it jumps straight to local access without the indirection provided by an XRIDescriptor. I'd much prefer that resolution of the above strip off the path (/foo), do some sort of transform on the base and retrieve an XRID that explains how the path portion can be accessed. In other words, I'd like resolution of xri://xri.epok.net/foo to be more aligned with resolution for xri:@epok/foo.
 
-- Proxied resolution
 
The 1.0 spec doesn't mention proxy resolvers and appears to encourage clients to go to the true naming authority for each segment. This places an unnecessary burden on the root and other high-level naming authorities. We should consider a revision that at a minimum explains how proxies would work in this system. If we do this, we need to pay attention to its impact on trusted resolution, both on the formal trusted res spec and on trust implications to simple trusted res using https.
 
-- Look ahead resolution
 
This is potentially related to proxied resolution, but I split it out because it's logically distinct. The current spec requires that XRI authorities be resolved one subsegment at a time without the possibility of "look ahead". In some cases, this creates an odd tension between efficiency and flexibility for an XRI author.
Let's say, for example, that you wanted to construct an XRI from the telephone number +1-234-567-8901. A flexible design would split the number between each digit, a la ENUM, but this makes resolution very expensive since each digit represents a roundtrip to a resolver. I'm not sure what the right answer is, but I think this is worth discussing.
 
-- Updated ABNF
 
Right now we have a pretty crazy BNF, based in large part on draft 3 of 2396bis. It doesn't match 2396 and it won't match whatever RFC comes out of 2396bis since drafts 4 and 5 made significant changes. Although it's tedious and will require nontrivial changes to text, we should probably update our BNF to match 2396bis.
 
-- Updated IRI
 
IRI (Internationalize Resource Identifier) has gone through several drafts since XRI 1.0 was released. We should review the current rev and make appropriate changes, especially since IRI was just submitted to IESG, which presumably reflects its stability.
 
-- Review of Sections 2.2.4.3, 2.2.4.4, 2.2.4.5
 
These all deal with transformation algorithms that I don't think anyone has implemented yet. These are fairly complicated and really need close review so we're reasonably sure they're correct.
 
-- Proposed Errata
 
There are several formally proposed errata that should be discussed and potentially incorporated.
 
-- New XRIDescriptor elements
 
There are several XRID elements added by the trusted res draft that are potentially useful in standard resolution. We should evaluate and include as needed.
 
Again, please feel free to add others. Also, please comment on this list, although detailed discussions of any of these issues should probably be done in their own threads.
 
Dave


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]