URGENT: 2 Major Issues with RC1

["Drummond Reed" <drummond.reed@onename.com>]

Editors:

It's times like this that make me reconsider the job of final spec
editing coordination. After completely blowing out my schedule for the
last two weeks trying to get everything done by this Thursday's voting
deadline, Dave and I just spent 1.5 hours on the phone discussing two
snags with RC1 that require serious consideration by the Editors as to
whether we need to take more time to resolve them.

I'm writing this email just to explain the issues. See the end of it for
my conclusion about how we should try to resolve this.

The two issues are:

1) Separating out Appendix B, the $ space, into a separate spec, and
2) Defining the canonical form of an XRI.

Following are details on each.

APPENDIX B - THE $ SPACE

In his comments sent to the Editor's list on RC1b, Dave observed that
Appendix B is "underspecified". Given the importance of $ metadata to
XRI architecture, I'm afraid I have to agree with him. It was my
responsibility to draft this appendix, which has been simply as a bullet
point list of the $ identifiers we have been compiling as we wrote the
spec, and I admit I put it off until the end (because it was an
appendix!!). 

When I finally got around to drafting the text, I realized that some of
these, like $!, required more than just listing in an appendix. $l and
$f are already discussed (though I think not enough) in the main spec.
So are $s and $s.a in the resolution section, and $t in Appendix D. But
$v, which may be the single most important $ identifier of all, and $q
are not discussed anywhere.

Dave's suggestion, which made me cringe but also made sense, is that we
consider separating out Appendix B into a second spec, which for
purposes of discussion we called the XRI Metadata Specification. One of
the main reasons we agreed we should consider this is that the $ space
is likely to evolve fairly rapidly over the next year, and it would be
nice to be able to rev the Metadata spec separately from the main spec. 

This of course raises all kinds of questions about how we would deal
with $ identifiers which are an integral part of the current spec ($f,
$l, $s, $t). The main ideas Dave and I discussed were to:

a) Specify in the main spec any $ metadata necessary for the main spec.
Otherwise specify that the Metadata spec is authoritative for all other
$ metadata.

b) Specify in the main spec that the Metadata spec will define two
classes of metadata for the purposes of equivalence - significant and
insignificant. All insignificant metadata would be separated into one
space (tentatively $!) so that it can easily be ignored by an XRI
processor. All other $ metadata SHOULD be considered significant.

CANONICAL FORM

The second point, made by both Gabe and Dave in their feedback on RC1b,
is that we don't really define a canonical form of an XRI. My edit in
RC1b changed the heading of the "Optional Syntax" subsection in
Normalization and Comparison to "Canonicalization", but otherwise just
left it as a set of equivalence rules.

Dave and I discussed this at length and agreed that our instincts tell
us that given the equivalence rules we have enumerated, it would make it
significantly easier for implementers if we took the time to define
canonicalization rules. Dave has volunteered to do this if we agree it
makes sense.

CONCLUSION

Right now, having spent 2.5 hours thinking about this (on not enough
sleep last night), my gut feeling is that, as painful as it is, we
should do both of the above. It breaks into 2 chunks of work:

1) Rewriting RC1b to separate out Appendix B and reference a separate
Metadata Spec (2-3 hours - I would volunteer for this).
2) Drafting and integrating the canonicalization rules (3-4 hours - Dave
would volunteer for this).

Although theoretically this could be accomplished by Thursday, these
changes are major enough that they would require another round of review
by the Editors and the TC members. So realistically, we're looking at
another 2 week cycle (1 week to draft and polish, one week to review
before a vote).

So, how does everyone else feel about this? Since I'll be offline at
meetings most of tomorrow, let's try to close this by email in the next
24 hours so we know what should communicate to the rest of the TC
members by Wednesday.

=Drummond