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

[Ari Keränen <[e-mail]>]

Hi Klaus,

> On 22 Jan 2019, at 14.01, Klaus Hartke <[e-mail]> wrote:
> 
> 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.

Nothing obvious comes to my mind, but I remember in some other contexts (e.g., HITs in HIP specs; which are essentially IPv6 addresses) we were careful to remind about the byte order, especially for crypto operations. But perhaps that is not that relevant here, so I'm fine either way.

>> 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.

Sounds good, thanks!

> 
>>     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?

Seems like a sensible design choice. But since it's non-obvious, should it be mentioned somewhere in the document?

>> 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+.-]*"),
>              ...

Does this mean also control characters like new-line are OK, or is there need for restricting that? Should we express the need for percent-encoding in CDDL? 


Cheers,
Ari