[core] Review of CIRIs (was: Review of CoRAL)

[Klaus Hartke <[e-mail]>]

Hi Christian,

thanks again for your review. Here's the next batch of replies, this
time related to CIRIs.

Christian Amsüss wrote:
> * Appendix C: Do I understand correctly that there are some CBOR encoded
>   relative references that can not (even when knowing the rel in
>   append-relation) be expressed in a relative-ref? In particular, those
>   would be the append-* types. If so, it would be prudent to point out
>   right next to where it says that "CBOR-encoded IRI References are not
>   capable of expressing all IRI references".

In principle, it is always to possible to use IRIs everywhere.
Relative references are more like a compression mechanism that allows
us to write IRIs more efficiently when they share a common base. In
that sense, there are no CIRI references that cannot be expressed by
an IRI reference:

    ciri_ref_to_iri_ref(ciri, base_ciri) = make_iri_relative(
                    ciri_to_iri(resolve_ciri(ciri, base_ciri)),
                    ciri_to_iri(base_ciri))

> * Most of the URI resolution gets away without string comparisons. I'd
>   like to suggest making "../" an explicit URI option (say, a `*(parent:
>   5.5)` that'd go between path.type and and path. References with
>   dot-segments inside them are probably safe to put in the "not capable
>   of expressing all" category.

Good idea. My proposal would be to use the path.type option for this:

   path.type
      Specifies the type of the URI path for reference resolution.  The
      option value is an integer in the range 0 to 127, named as
      follows:

         0 - absolute-path
         1 - append-relation
         2 - append-path
         3 - relative-path
         4 - relative-path-1up
         5 - relative-path-2up
         6 - relative-path-3up
         7 - relative-path-4up
         ...

   path
      Specifies one segment of the URI path.  The option value can be
      any Unicode string with the exception of the strings "." and "..".
      This option can occur more than once.

>   As I understand URI resolution, we don't need a "./" because that only
>   needs to be explicit when starting with something that has a colon in
>   it that's not the scheme's colon, otherwise "./x/y" is always
>   equivalent to "x/y".

Good point. Removed with the above proposal.

> * Speaking of expressiveness of the encoded URIs: (Especially as urn: is
>   used in the document,) would it hurt to grow the encoded references
>   such that they can encode urns? It might be sufficient to allow scheme
>   without a host/port but a path.

Makes sense. It would be good to know that set of URIs we want to
support exactly and what the scheme-specific normalization rules are
for these (see also the discussion on comparisons in [1]).

>   Apropos port: Why must this be present after a host name? This
>   complicates round-tripping to URIs (because the algorithm has to know
>   to fill in default ports of all protocols), limits applicability to
>   portless protocols and adds some bytes -- and in the embedded
>   implementation, adding a default port can be as easy as just setting
>   it at initialization time before parsing.

Ari also brought this up in his review. See the discussion in [1].

> * Appendix C: A state transition diagram like the ones on
>   http://json.org/ could be as expressive as the list in C.3 while being
>   easier to grasp.

Added in -00.

> * How are compressed URIs expressed in CBOR? Flat [6, "foo", 6, "bar"]
>   or nested [[6, "foo"], [6, "bar"]]? My first reading (and current
>   implementation) resulted in "nested", supported by the `(option,
>   value) = href[0]` line in C4, but reading C.1 with the CDDL spec next
>   to it (and running the cddl tool) rather indicates "flat" to me.

Flat [6, "foo", 6, "bar"]. I'm adding a clarification and some
examples in the next draft revision.

>   Either way, some examples would be great.

Agreed. Working on it.

> * Nit: calling a sequence of options _absolute_ brings up the
>   association of the "absolute URI", which is not the same as "URI"
>   (which is by definition not a reference, but sometimes it helps to say
>   "full URI"). An Absolute URI would not have a fragment identifier (and
>   is defined to ease definign protocols where the fragment is never
>   sent), whereas the non-relative or full option sequence described here
>   can easily (and should be able to) contain a fragment identifier.

I see the potential confusion, but I don't have a good idea how to
phrase it in a better way. Any suggestions?

Klaus

[1] https://mailarchive.ietf.org/arch/msg/t2trg/7RIEEHql5Jm70TAzlOuQeXAwNfc