Re: [core] WG Last Call on draft-ietf-core-href-13

[Marco Tiloca <[e-mail]>]

Hi all,

Please find below my WG Last Call review.

Best,
/Marco

================

[Section 1]

* When mentioned in the third and fifth paragraphs RFC 3986 is not 
rendered as a link.


[Section 2]

* In C9, it is said: "If no authority is present in a CRI, the leading 
path segment cannot be empty. (See also SP1 in Appendix B.)"

    Isn't it better to mention that already when earlier discussing C2?


[Section 5.1]

* "two leading null values (scheme and authority both not given) MUST be 
represented by using the discard alternative instead, and"

   Is this actually the only case where to use discard?

   Scheme and authority are both not given also in case the first two 
elements in the outer array are null (absent scheme) and true (absent 
authority followed by rootless path). Shouldn't discard be used also in 
this case?

* "an empty path in a CRI MUST be represented as the empty array [] 
(note that for CRI-Reference there is a difference between empty and 
absent paths, represented by [] and null, respectively),"

    Figure 1 still admits null as possible encoding of path also in a 
CRI. What is its meaning in that case?

    (Note that the distinction above between absent (=null) and empty 
(=[]) path is limited to CRI references, as expected)

    This is still useful, in the interest of eliding a sequence of 
trailing null, but Section 5.2 focuses only on CRI references.

    It feels like, in a CRI: null does not have an actual meaning for 
path, which can simply be an array, possibly empty to indicate the empty 
path; when converting from abstract to transfer form, the empty array is 
converted to null; when converting from transfer form to abstract form, 
a null for the path element becomes the empty array encoding the empty path.

* "an entirely empty outer array is not a valid CRI reference."

    Nor a valid CRI, right?


[Section 5.1.1]

* "correspond to the CRI form that starts with discard"

    I think you mean "correspond to the CRI reference form that starts 
with discard", since discard is limited to CRI references.


[Section 5.1.3]

* In the third example, "NOAUTH-NOSLASH" should be "NOAUTH-ROOTLESS"


[Section 5.1.4]

* In the three paragraphs, "if" is used. Do you actually mean "if and 
only if"?

* "A CRI reference is considered relative if it is well-formed and the 
sequence of sections is empty or starts with a section other than those 
that would constitute a scheme."

    I'm probably misreading this, but how can the sequence of sections 
be empty and well-formed at the same time? Section 5.1 states that an 
entirely empty outer array is not a valid CRI reference.


[Section 5.2]

* "If scheme and/or authority are present in the transfer form (i.e., 
the outer array starts with null, a text string, or a negative integer), 
set discard to true."

    Isn't it sufficient to say: "If scheme is present in the transfer 
form (i.e., the outer array starts with null, a text string, or a 
negative integer), set discard to true." ?


[Section 5.3]

* "If the value of discard is true in the CRI reference (which is 
implicitly the case when scheme and/or authority are present in the 
reference), ..."

    From the ingesting process in Section 5.2, I understand that at this 
point both scheme and authority are *present* as element of the CRI 
reference as a data structure, with a value admitted by the CDDL 
definition in Figure 1.

    You probably mean: "which is implicitly the case when scheme is 
non-null and/or authority is neither null nor true in the CRI reference".


[Sections 10.1.1 and 10.1.3]

* There is now a forward reference to Table 1. Please add a reference to 
Appendix A including it.


[Appendix A]

* Like in Section 5.1, please use "RFC-XXX" and add the note "RFC Ed.: 
throughout this section, please replace RFC-XXXX with the RFC number of 
this specification and remove this note."


[Appendix C]

* Would it be possible to have an aggregated entry "Changes from -09 to 
-13" ?


[Nits]

* Section 1
--- s/comparison and reference/comparison, and reference

* Section 2
--- s/Note that in Figure 1,/Note, that in Figure 1,
--- s/of [RFC3986], not/of [RFC3986]), not

* Section 5.1
--- Please add a line break between "as follows:" and "RFC Ed.:"

* Section 5.2.1
--- s/adhere to rules/adhere to these rules

* Section 6
--- s/references and IRI/references, and IRI

* Section 6.1
--- s/registry Section 10.1./registry (Section 10.1).

* Section 7
--- s/recipients o CRIs/recipients of CRIs

* Section 10.1
--- s/the to be/them to be

* Acknowledgements
---s/Thaler and Marco/Thaler, and Marco


On 2023-07-11 11:17, Marco Tiloca wrote:
> Dear all,
>
> This email starts a Working Group Last Call for the document
>
> https://datatracker.ietf.org/doc/html/draft-ietf-core-href-13
>
> (Constrained Resource Identifiers)
>
>
> The document status can be found at:
>
> https://datatracker.ietf.org/doc/draft-ietf-core-href/
>
>
> Please provide your comments and feedback by Monday, 2023-07-24, which 
> allows us to have a follow-up discussion during the CoRE session at 
> IETF 117 the day after.
>
> Best,
> /Marco
> -- 
> Marco Tiloca
> Ph.D., Senior Researcher
>
> Phone: [phone]
>
> RISE Research Institutes of Sweden AB
> Box 1263
> 164 29 Kista (Sweden)
>
> Division: Digital Systems
> Department: Computer Science
> Unit: Cybersecurity
>
> https://www.ri.se
>
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core

-- 
Marco Tiloca
Ph.D., Senior Researcher

Phone: [phone]

RISE Research Institutes of Sweden AB
Box 1263
164 29 Kista (Sweden)

Division: Digital Systems
Department: Computer Science
Unit: Cybersecurity

https://www.ri.se