[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Initial proposed XRI 1.1 ABNF and issues analysis
XRI TC Members and Observers,
This email contains:
A) An initial proposal for the XRI 1.1 ABNF, and
b) An analysis of how this proposed ABNF would resolve the syntax-related
issues listed in previous emails to the list (and compiled at
http://xrixdi.idcommons.net/moin.cgi/Xri1xIssuesList.)
Note that this is only a proposal prepared by several members of the
Editor's SC and does yet not mean there is consensus on the proposed
resolutions to some issues. It is designed to move these ideas into broader
discussion by all members of the TC.
If you wish to view this proposal in web page format, it is available at
http://xrixdi.idcommons.net/moin.cgi/Xri1dot1ProposedAbnf.
=Drummond
******PART ONE - PROPOSED XRI 1.1 ABNF********
== Proposed ABNF in Specification Order ==
This section presents the ABNF in the proposed logical order in which the
productions will be covered in the XRI 1.1 specification.
''Note: This structure is a slight revision from the 1.0 spec. In this
proposed structured, all XRI-only productions are given first, followed by
all productions inherited from IRI, and lastly all productions IRI inherited
from URI. This seems like a logical order and shows the evolutionary
relationships of the syntactic structures.''
=== XRI Productions ===
==== Syntax Components ====
{{{
XRI = absolute-xri / relative-xri
absolute-xri = ["xri:"] global-path [ "?" xri-query ]
[ "#" xri-fragment ]
global-path = authority-path [ local-path ]
local-path = "/" relative-path
relative-path = xri-segment * ( "/" xri-segment ) [ "?" xri-query ]
[ "#" xri-fragment ]
relative-xri = local-path / relative-path
xri-value = global-path / local-path / relative-path
}}}
==== Authority ====
{{{
authority-path = XRI-authority / IRI-authority
XRI-authority = ( gcs-char [ xri-segment ] ) / xref-authority
gcs-char = "=" / "@" / "+" / "!" / "$"
xref-authority = xref *( xri-sub-delims sub-segment )
xref = "(" ( xri-value / IRI ) ")"
IRI-authority = "//" iauthority
}}}
==== Path ====
{{{
xri-segment = sub-segment *( xri-sub-delims sub-segment )
sub-segment = ( *xri-pchar / xref )
xri-pchar = xri-unreserved / pct-encoded / xri-sub-delims
}}}
==== Query ====
{{{
xri-query = [ xref ] *( xri-pchar / iprivate / "/" / "?"
/ ":" / "[" / "]" / "@" / "(" / ")" / "!" / "$"
/ "*" / "+" / "=" )
}}}
==== Fragment ====
{{{
xri-fragment = [ xref ] * ( xri-pchar / "/" / "?"
/ ":" / "[" / "]" / "@" / "(" / ")" / "!" / "$"
/ "*" / "+" / "=" )
}}}
==== Characters ====
===== Reserved =====
{{{
xri-reserved = xri-gen-delims / xri-sub-delims
xri-gen-delims = "/" / "?" / "#" / "[" / "]" / "@" / "("
/ ")" / "!" / "$" / "+" / "="
xri-sub-delims = "!" / "*" / "&" / ":" / ";" / "," / "'"
}}}
===== Unreserved =====
{{{
xri-unreserved = unreserved / ucschar
}}}
=== IRI Productions ===
{{{
IRI = scheme ":" ihier-part [ "?" iquery ]
[ "#" ifragment ]
scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
ihier-part = "//" iauthority ipath-abempty
/ ipath-abs
/ ipath-rootless
/ ipath-empty
}}}
==== Authority ====
{{{
iauthority = [ iuserinfo "@" ] ihost [ ":" port ]
iuserinfo = *( iunreserved / pct-encoded / sub-delims / ":" )
ihost = IP-literal / IPv4address / ireg-name
IP-literal = "[" ( IPv6address / IPvFuture ) "]"
IPvFuture = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )
IPv6address = 6( h16 ":" ) ls32
/ "::" 5( h16 ":" ) ls32
/ [ h16 ] "::" 4( h16 ":" ) ls32
/ [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32
/ [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
/ [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32
/ [ *4( h16 ":" ) h16 ] "::" ls32
/ [ *5( h16 ":" ) h16 ] "::" h16
/ [ *6( h16 ":" ) h16 ] "::"
ls32 = ( h16 ":" h16 ) / IPv4address
h16 = 1*4HEXDIG
IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet
dec-octet = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199
/ "2" %x30-34 DIGIT ; 200-249
/ "25" %x30-35 ; 250-255
ireg-name = *( iunreserved / pct-encoded / sub-delims )
port = *DIGIT
}}}
==== Path ====
{{{
ipath-abempty = *( "/" isegment )
ipath-abs = "/" [ isegment-nz *( "/" isegment ) ]
ipath-rootless = isegment-nz *( "/" isegment )
ipath-empty = 0<ipchar>
isegment = *ipchar
isegment-nz = 1*ipchar
}}}
==== Query ====
{{{
iquery = *( ipchar / iprivate / "/" / "?" )
iprivate = %xE000-F8FF / %xF0000-FFFFD / %x100000-10FFFD
}}}
==== Fragment ====
{{{
ifragment = *( ipchar / "/" / "?" )
}}}
==== Characters ====
{{{
ipchar = iunreserved / pct-encoded / sub-delims / ":"
/ "@"
iunreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" / ucschar
pct-encoded = "%" HEXDIG HEXDIG
ucschar = %xA0-D7FF / %xF900-FDCF / %xFDF0-FFEF /
%x10000-1FFFD / %x20000-2FFFD / %x30000-3FFFD /
%x40000-4FFFD / %x50000-5FFFD / %x60000-6FFFD /
%x70000-7FFFD / %x80000-8FFFD / %x90000-9FFFD /
%xA0000-AFFFD / %xB0000-BFFFD / %xC0000-CFFFD /
%xD0000-DFFFD / %xE1000-EFFFD
}}}
=== URI Productions ===
==== Characters ====
{{{
reserved = gen-delims / sub-delims
gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
}}}
******PART TWO - ANALYSIS OF HOW IT ADDRESSES SYNTAX ISSUES********
== Proposed Resolution of Syntax Issues ==
This section summarizes the proposed resolution of each outstanding syntax
issue on Xri1xIssuesList and its effect on the ABNF above.
=== Star Semantics ===
See XriChangeStarSemantics.
The proposed resolution is to incorporate the following design changes in
XRI 1.1:
1. ''Allow subsegments to be null.'' This aligns with RFC2396bis, which
also allows null segments, and enables combinations of delimiters to be used
together (e.g., "/*", "/!", "/*!") for addressing along multiple axis of a
resource graph (as is done in XPath, and required in XDI.)
2. ''Allow any xri-subdelims to delimit a subsegment.'' This generalizes
the concept of subsegment and allows other delimiters besides the dot and
colon allowed in XRI 1.0. ''Note that since dot is no longer a reserved char
in RFC2396bis, it is no longer one of the xri-subdelims.''
3. ''Designate bang ("!") as the xri-subdelims character for persistent
subsegment values at all levels of an XRI.'' This replaces colon because
colon has a reserved role in URI authorities, and it is proposed that XRI
authorities become compatible with RFC2396bis authorities (see below). This
also provides alignment with the proposed new role of ! as the GCS character
for independent persistent XRIs.
4. ''Designate star as the xri-subdelims character for delegation of a
reassignable subsegment within an XRI authority segment.'' This replaces the
role of dot in XRI 1.0.
5. ''In XRI 1.1 resolution of an XRI authority segment, designate that the
delimiters for null subsegments are ignored.'' For example, the XRI
authority segments "@!1234!5678" and "@!1234*!5678" are equivalent because
the null subsegment delimiter "*" is ignored.
The changes to the ABNF are:
* XRI segments and subsegments are now more generalized, as any XRI
subdelimiter may be used to delimit a subsegment, and subsegments can now be
null, allowing for the use of multiple xri-sub-delims for multi-axis
addressing.
{{{
xri-segment = sub-segment *( xri-sub-delims sub-segment )
sub-segment = ( *xri-pchar / xref )
}}}
* Cross-reference authorities now use the more generalized XRI subsegments.
{{{
xref-authority = xref *( xri-sub-delims sub-segment )
}}}
=== Align XRI Authority to be RFC 2396bis-style Authority ===
See XriChangeAuthority.
The proposed resolution is that XRI authorities incorporate the following
design changes to conform to the RFC2396bis ''authority'' production (the
''iauthority'' production in our ABNF). This would enable XRI relative
references to conform to the same relative resolution rules as URI relative
references. It would also mean that an XRI authority can be treated as a
RFC2396bis ''reg-name'' (registered name) according to RFC2396bisv6.
''Note that this is only possible to the efforts of XRI Editor's SC chair
Dave McAlpin, who convinced the authors of RFC2396bis dropped the
255-character limit on the reg-name production which would have made it all
but impossible to pursue interoperability with the RFC2396bis authority
production. Dave is now
[http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html#ack credited in
RFC2396bis for this change]. Congrats, Dave!''
Interoperability can now be accomplished with nominal cost to the design
goals of XRIs with the following two design changes:
==== Keep "xri:" and "//" Optional in Native XRIs ====
Since RFC2396bis authorities must start with "//", yet native absolute XRIs
can start with just a single GCS character or a cross-reference, the
proposed solution is that:
1. The "xri:" scheme name and the "//" authority prefix would both optional
in a native XRI, i.e., prior to conversion to XRI normal form.
2. The "//" authority prefix would optional in XRI normal form, but
required to be inserted between "xri:" and the XRI authority segment in the
transformation to IRI normal form.
==== Define Rules Separating XRI Authorities and IRI Authorities ====
In XRI 1.0, XRI authorities and URI authorities (all authority types allowed
by the "authority" production in RFC2396bis), were separated syntactically
because all URI authorities began with "//". To become interoperable with
RFC2396bis authorities, we can no longer distinguish by this syntax alone.
XRI authorities and IRI authorities (all authority types allowed by the
"iauthority" production in IRI) must share the same namespace under "//"
within the "ireg-name" production, as shown by the relevant productions
below:
{{{
iauthority = [ iuserinfo "@" ] ihost [ ":" port ]
iuserinfo = *( iunreserved / pct-encoded / sub-delims / ":" )
ihost = IP-literal / IPv4address / ireg-name
IP-literal = "[" ( IPv6address / IPvFuture ) "]"
IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet
ireg-name = *( iunreserved / pct-encoded / sub-delims )
iunreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" / ucschar
pct-encoded = "%" HEXDIG HEXDIG
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
}}}
A clean separation can still be accomplished by the following rules:
1. All characters which may legally start a DNS name (letter or digit),
IPv4 address (digit), or IPv6 address (square brackets) are reserved for IRI
authorities.
2. All other characters which may legally be used as the first character of
the ''host'' production of RFC2396bis (or the ''ihost'' production in our
ABNF), are reserved as the starting character of an XRI authority.
3. In addition, the @ character, which is reserved as the delimiter between
the userinfo production and the host production in RFC2396bis, is reserved
as the starting character of an XRI authority.
This means an authority-path in XRI 1.1 MUST begin with one of the
characters in the following two sets:
1. GCS authority characters: = @ + $ !
2. Cross-reference authority character: (
It also means the following characters are reserved in case there is ever a
need to add another XRI authority character in the future: - . _ ~ & ' ) *
, ;
If an XRI authority-path segment begins with any other character, it is an
IRI authority and must conform to the IRI iauthority production.
=== Redefinition of GCS "!" Character ===
See XriChangeNewGcsChar.
In XRI 1.0, the GCS ! character was used for annotations. The proposed
change in XRI 1.1 is to redefine the ! character as the GCS character for
independent global i-numbers - i-numbers that represent physical or network
assets that may change ownership over time and therefore need to be
identified independent of an =, @, +, or $ context.
(It is proposed that annotations be moved to a subchar under the $ character
in XRI Metadata Spec, for example, "$-".)
This design also aligns with the proposed redefinition of ! as the
xri-subdelims character for persistent subsegment values. An absolute
persistent XRI would now begin with double bang ("!!") just as an absolute
URI begins with double slash ("//"). Examples:
{{{
!!1234!5678/!A1B2
xri:!!1234!5678/!A1B2
xri://!!1234!5678/!A1B2
}}}
The only affect on the XRI 1.1 ABNF in comparision to XRI 1.0 is to drop "*"
as a GCS character, since it is now used only as an xri-subdelim.
{{{
gcs-char = "=" / "@" / "+" / "!" / "$"
}}}
=== Harmonizing XRI 1.1 with New Drafts of 2396bis and IRI ===
See XriChangeNewAbnf.
''These remaining issues, which are fairly minor, are not yet resolved.
Depending on the resolution they may or may not result in any further
changes to the ABNF.''
=== No Requirement for Relative Subsegment Resolution ===
See XriChangeRelativeResolutionForSubsegments.
The proposed resolution of this issue is that XRI 1.1 need not define
resolution of relative subsegments outside of the XRI authority resolution
rules that would apply to * and ! subsegments only. This is because the
requirements of XRI applications like XDI can be met through multi-axis
addressing using null subsegments.
The 1.1 specification could point out that XRI authority resolution is just
one example of subsegment resolution rules for multi-axis addressing that
are possible using XRI syntax.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]