Resolution of RFC2396bis alignment issues

["Drummond Reed" <drummond.reed@cordance.net>]

XRI TC Members and Observers,

Attached below, and posted as a wiki page at
http://xrixdi.idcommons.net/moin.cgi/XriChangeNewAbnf, is a summary of the
resolution of four issues related to aligning XRI 1.1 syntax with that of
RFC2396bis.

The editors have not yet updated the proposed XRI 1.1 ABNF to reflect these
changes; it will be posted once that is done.

=Drummond 


'''This page covers the outstanding issues related to align XRI 1.1 syntax
with RFC2396bis and IRI.'''

== Issues ==

=== Fragment Usage ===

We allow fragment in an absolute XRI. This is different than in URI and IRI.
For example, in RFC2396bis, fragment is allowed in <URI>, not in
<absolute-URI> (likewise for IRI). What we call <XRI> is comparable to what
2396bis calls <URI-reference>. What we call <absolute-XRI> is comparable to
<URI>. We don't have an equivalent of <absolute-URI> (which excludes
fragment). A base URI in relative reference resolution must be in the form
of <absolute-URI>. 

==== Resolution ====

 1. Align XRI 1.1 with RFC2396bis on production names.
 1. Align fragment usage, i.e., allow fragments in matching productions.

=== Null Segments ===

Should we allow xri-segments (and thus relative-path) to be null, i.e.,
"foo/////bar". This is legal in conventional URIs under 2396bis.

==== Resolution ====

Yes, this should be aligned with RFC2396bis.

=== Explicit Mention of Xref in Xri-Query and Xri-Fragment ===

In XRI 1.0, xref is mentioned explicitly in xri-query. It may be better to
just allow parens. Otherwise it could require percent encoding of parens in
XRIs included in a query's name/value pair. Same comment for fragment.

==== Resolution ====

Remove explicit support for xref and instead reallow parens in the path.

=== Xri-Gen-Delims in the Path ===

All xri-gen-delims are disallowed in a path, so they must be percent encoded
if they don't have their defined syntactic meaning. For example, something
like xri:@foo/@bar is illegal - the second @ sign must be percent encoded.
Is this the behaviour we want?

==== Resolution ====

Yes. This explicitly means that GCS chars do not have to be percent-encoded
when used in syntactically-correct cross-references, but must be
percent-encoded otherwise. This behaviour will help prevent semantic attacks
with XRIs.