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

[Klaus Hartke <[e-mail]>]

Ari Keränen wrote:
> > 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?

Yes. The section on comparisons is currently missing, mostly because
I'm not sure if we actually need to be able to compare. If not, we
could also support URI schemes with different normalization rules. So,
as mentioned in [1], it would be nice to have a discussion on what URI
schemes we want to support and whether comparisons are actually
needed.

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

I don't see anything in RFC 3986 that would prevent percent-encoded
control characters e.g. in a path segment:
<http://example.com/First%20Line%0D%0ASecond%20Line/>.

Since in CBOR text strings are prefixed by their length, we don't need
to do any percent encoding there:
[1, "http", 2, "example.com", 4, 80, 6, "First Line\r\nSecond Line", 6, ""]
(in CBOR diagnostic notation).

Klaus

[1] https://mailarchive.ietf.org/arch/msg/core/ITSAbkgxMhlgzwn-20Jtk6mfN04