Re: [T2TRG] draft-hartke-t2trg-ciri-00 review

[Klaus Hartke <[e-mail]>]

Hi Ari,

thanks a lot for your review!

Ari Keränen wrote:
> 2.1.  Options
>
>     host.ip
>       Specifies the host of the IRI authority as an IPv4 address
>       (4 bytes) or an IPv6 address (16 bytes).
>
> Do we need endianess considerations here? Or does CBOR take care of that?

Is there any protocol or format that does not encode 192.0.2.42 as
h'C000022A' or [2001:db8::42] as h'20010DB80000000000000000000042'? I
always thought that IP addresses do not have an endianness.

> 2.2.  Option Sequences
>
>      A sequence of options is considered _well-formed_ if:
>
> Do we need the _emphasis_ here? Maybe in quotes since it's a defined
> term? Unless we want to follow the CDDL convention -- which perhaps
> makes sense. But then it's probably good to have a note along the lines
> of "New terms are introduced in _cursive_." in the terminology section.

Yes, the idea was to write terms defined by the document in cursive
where they are introduced. I'll add a note to the terminology section.

>      o  a "host.ip" option is followed by a "port" option;
>
> Why is the port option mandatory? No default ports allowed?

This is relates to a tricky question regarding design goals.

As defined by RFC 3986, URIs can often be written in a number of ways:

* Schemes can be written in upper- or lowercase but are case-insensitive.
* Registered name are case-insensitive as well.
* Hex characters in percent encodings are case-insensitive as well.
* Schemes can define scheme-specific rules. E.g., in the case of "coap":
    * The port 5683 and an omitted port are equivalent.
    * The path "" and "/" are equivalent.

The primary function of CIRI References is to dereference them (where
RFC 3986 defines "dereferencing a URI" as using an access mechanism
determined by "URI resolution" to perform an action on the URI's
resource). For that, a client only needs to compare URI schemes, pass
registered names to a name resolution service, and know the default
ports of the protocols it actually implements.

The question is if we secondarily also want to be able to compare
CIRIs. Normally, because of all of these normalization rules, this is
quite tricky to do for all URI schemes (in particular if a URI scheme
has scheme-specific rules and is not recognized by an implementation).
However, if we restrict CIRIs to follow the normalization rules of
CoAP, then we can actually support any URI scheme with the same
normalization rules (such as HTTP) with ease. The only thing we need
to know to successfully compare two CIRIs with an unrecognized scheme
is - the default port.

So, at the cost of two bytes in a CIRI with a default port, we gain
that we can compare any supported CIRI even when the scheme is
unrecognized. Is it worth it? In my opinion, yes - if we want to be
able to compare CIRIs. On that, I don't have a good opinion yet. What
do you think?

> 3.  CBOR
>
>        ciri = [?(scheme:    1, text),
>                ?(host.name: 2, text //
>                  host.ip:   3, bytes .size 4 / bytes .size 16),
>                ?(port:      4, uint .size 2),
>                ?(path.type: 5, path-type),
>                *(path:      6, text),
>                *(query:     7, text),
>                ?(fragment:  8, text)]>
>
> Isn't "text" too permissive type for most (all?) of the components?

RFC 3986 actually makes no restrictions at all on what characters can
be used in registered names, paths segments, queries and fragment
identifiers. (The only requirement is that some of them need to be
percent-encoded.) So, as I understand it, "text" (a.k.a. "tstr") is
the right match here.

The scheme is restricted with a regex in -00:

      ciri = [?(scheme:    1, text .regexp "[A-Za-z][A-Za-z0-9+.-]*"),
              ...

Klaus