xri message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Possible changes to XRI 1.0
- From: "Dave McAlpin" <Dave.McAlpin@epok.net>
- To: <xri@lists.oasis-open.org>
- Date: Thu, 3 Jun 2004 19:49:56 -0400
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]