Comment on Akoma Ntoso Naming Convention

[Tara Athan <taraathan@gmail.com>]

The document states that International Resource Identifier as per RFC 3987 (http://tools.ietf.org/html/rfc398) is a normative reference. Therefore the document should use the terminology introduced in RFC 3987 according to the definitions provided in RFC 3987.

In Section 4.2, the following is stated:
"According to the authoritative source RFC 3986, all http:// IRI references are divided into absolute IRI and relative IRI references. "

One must be careful here. RFC 3986 defines URIs, not IRIs.

The precise quote from RFC 3987 is

"IRI reference: Denotes the common usage of an Internationalized Resource Identifier. An IRI reference may be absolute or relative. However, the "IRI" that results from such a reference only includes absolute IRIs; any relative IRI references are resolved to their absolute form. "

Based on this definition, there are two cases of IRI references:
1. an IRI reference that is absolute (also called an absolute IRI, or simply IRI)
2. an IRI reference that is a relative (also called a relative IRI reference)
RFC 3987 only uses the phrase "absolute IRI" once, for emphasis. Elsewhere, it simply uses IRI.

This is supported by the ABNF rule from 3987

IRI-reference  = IRI / irelative-ref

In contrast, Akoma Ntoso Naming Convention states

"In the following we will call all IRI

references as simply IRI (they are all references, after all), and distinguish between absolute IRIs, global IRIs and local IRIs."

RFC 3986 uses the terminology  "absolute-path reference"/ "relative-path reference" for a relative URI reference that starts/doesn't start with a slash.

RFC 3987 doesn't use the term "absolute-path reference" directly, but does reuse the ABNF rule:

ipath-absolute = "/" [ isegment-nz *( "/" isegment ) ]

I appreciate the motivation for the introduction of the modifiers "global" and "local" to distinguish this partition of IRI references, as the reuse of "absolute" and "relative" to refer to paths may lead to confusion relative to absolute IRIs and relative IRI references. Further these terms are not used in RFC 3987, only in RFC 3986, so technically an absolute-path reference is a URI reference, not an IRI reference.

The main problem with the terminology of "global IRI" and "local IRI" is that these are not IRIs, they are IRI references, syntactically speaking.
While the terms "IRI" and "IRI" reference are often (incorrectly) used interchangeably in informal usage, in an OASIS standard these terms should be used correctly, formally, and not interchangeably.

Suggestions:
1. replace all occurrences of "global IRI" or "global IRI ref" with "global IRI reference"
2. replace all occurrences of "local IRI" or "local IRI ref" with "local IRI reference"

There is an additional aspect to this whole IRI/IRI reference issue, that is somewhat obfuscated by the misuse of terminology described above. Using "IRI" to refer to what are actually IRI references hides the fact that there is still a missing piece of information that must be obtained from somewhere in order to resolve this "global IRI" to an actual IRI - the domain name (and port, if appropriate). The Akoma Ntoso XML schema guarantees that this additional information cannot be specified explicitly in the Akoma Ntoso document - there is no xml-base attribute, or any other component that serves this purpose, and all IRI references are required to be relative.

I am especially concerned about this statement
"Any party interested in absolute IRIs for Akoma Ntoso are required to produce their own resolution engine and use its protocol and authority for the purpose."
I suppose this may be a practical necessity, given that there can be no real guarantee that a particular domain name is always owned by the legal system. However, it does depart from the ideal of the Web - that (absolute) IRIs are the identifiers. I would like to see the motivations and ramifications (e.g. security concerns) of this decision discussed in detail in the Standard, as it is setting a very significant precedent.

For example, suppose I decide to publish something at http://athant.com/akn/ke/debaterecord/2011-06-10/main that is similar, but not identical, to the example at http://docs.oasis-open.org/legaldocml/akn-core/v1.0/csprd01/part2-specs/examples/ke_Debate_Bungeni_2011-06-10.xml . Since this is my own domain, I am free to publish what I like there. But the path suggests that I am publishing a copy of the legal code with the identifier "/akn/ke/debaterecord/2011-06-10/main". This seems like a ripe opportunity for spoofing.

The above scenario contradicts the statement "This, in practice, means that protocol and authority are, in resolution, not contributing information, and are thus interchangeable.", which makes the assumption that the resource identified by the IRI having the given absolute path is the same as the official document. This is in fact the primary role of the "authority" component of an IRI - to establish a certain level of trust.

My feeling is that these things that are called "global IRI" and "local IRI" should not even be considered IRI references, since there is no set method for resolving them, so they don't refer to any particular IRI. These strings are in fact the identifiers in and of themselves. They have a certain resemblance to IRIs/IRI references, which is a convenience for processing, but they do not satisfy the definition of an IRI syntactically nor do they match the concept of an IRI reference from a functional perspective, and so shouldn't be considered as either. Why not call them something else, e.g. "global aknID", "local aknID", to make this clear?

Suggestions (preferred):
1'. replace all occurrences of "global IRI" or "global IRI ref" or "global IRI reference" with "global aknID", or something similar.
2'. replace all occurrences of "local IRI" or "local IRI ref" or "local IRI reference" with "local aknID", or something similar.


A couple of minor clarification in 4.2
3. clarify that only IRIs in the http scheme start with "http://"
" An absolute IRI starts with the string “http://”
should be
"An absolute IRI in the http scheme starts with the string “http://”

4. There are in fact network-path references (RFC 3986) that start with "//" and include the authority but not the scheme.

" A relative reference, on the other hand, has no indication of the scheme, no indication of the domain name, and may ..."
should be

" A relative reference, on the other hand, has no indication of the scheme, and may"

5. Clarify that IRI references are independent of the resolution mechanism, but that the resolved IRIs are (highly) dependent on this mechanism
"This makes all IRI references independent of the actual resolution mechanism, and allows for very flexible storage, access, and reference mechanisms. On the other hand, the resolved IRI is dependent on the resolution mechanism, which may supply the missing information from an arbitrary base IRI."

6. Typos
"In fact, this is a simplification of RFC 3986, that calls global IRI refs as “absolute path references” and local IRI refs as “relative path references”. "
should be
"In fact, this is a simplification of RFC 3986, that calls global IRI references as “absolute-path references” and local IRI refs as “relative-path references”."

7. Don't use "ref" as a word.

8. Proper attribution of IRI terminology to RFC 3987, and avoid usage of "absolute IRI reference", which does not appear anywhere in RFC 3987. Further, the scheme is irrelevant.

"According to the authoritative source RFC 3986, all http:// IRI references are divided into absolute IRI and relative IRI references."
should be
"According to the authoritative source RFC 3987, all IRI references are divided into absolute IRIs and relative IRI references."

Tara Athan
http://athant.com