[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]