Re: [core] Review of draft-ietf-core-coral-03

[Klaus Hartke <[e-mail]>]

Hi Jim,

thanks a lot for your review!

> Section 2.3 – Suggested text change s/are in contrast denoted/are, in contrast, denoted/  I keep thinking that by contrast should be used, but I keep going back and forth on that so I would leave that along.  If you go that it would be /types, by contrast, are denoted/

Yeah, I had a bit of trouble with that sentence due to having both "in
CoRAL" and "in contrast". I've fixed the sentence as you suggested.

> Section 2.3 – s/collisions when from different/collisions from/

The sentence currently says "This allows for the decentralized
creation of new link relation types without the risk of collisions
when from different organizations or domains of knowledge." With your
proposed change, it would be "This allows for the decentralized
creation of new link relation types without the risk of collisions
from organizations or domains of knowledge." That doesn't seem to say
the same thing... Maybe "This allows for the decentralized creation of
new link relation types without the risk of collisions when they come
from different organizations or domains of knowledge."?

> Section 2.3 – The CBOR WG is defining two new tags for Date and TimeOfDay.  Should these be added as new literal values?

I've added these to the list of open issues related to literals:
<https://github.com/core-wg/coral/issues/56>

Dates without time and times-of-day always run into interesting
problems regarding time zones... something is on June 9th, 2020, or
something is at 11 a.m. -- but in what timezone? Do you have an
example where you'd use Date or TimeOfDay in a CoRAL document; how
would you handle timezones there?

> Section 2.3 – s/is neither identified by/is identified by neither/

Fixed.

> Section 2.6 – Step 5 – Can the request method be a FETCH as well as a GET?

How would a client know whether to do a FETCH or a GET? Would a server
be required to always support both? What would be the expected payload
of the FETCH?

> Section 4.1.4 – I do not believe that expanding the MEDIAL character set is really a good idea.  Consider the following where one of the line uses HYPEN-MINUS and the other line uses ARMENIAN HYPEN.  I cannot see a difference if I am reading this.
> #using AB-CD = IRI1
> #using AB֊CD = IRI2

(The list of medials comes from
<https://unicode.org/reports/tr31/#Specific_Character_Adjustments>.)

The issue of glyphs looking visually similar is more general than just
the hyphens; it basically applies to all identifiers and IRIs in the
CoRAL textual format. For that reason, I've referenced
<https://www.unicode.org/reports/tr36/tr36-15.html#visual_spoofing>
and <https://www.rfc-editor.org/rfc/rfc6943.txt> in the security
considerations section . But maybe that's not enough?

> Section 4.1.5.3 – There is a difference between the text and the ABNF for hexadecimal.  One of them only has the lowercase character and the other has both upper- and lowercase ‘x’.

Fixed. Both upper- and lowercase 'x' are intended to be permitted.

> Section 5.2 – I am trying to figure out if not returning a CoRAL document is considered to be reasonable or not.  Does the phrase “processing result” indicate an absent content?

The section is intended to just define the meaning of a CoRAL document
when it occurs in different kinds of responses. It isn't meant to say
that every response must contain a CoRAL document :-)

> Section 5.2.1 – If I return a link to the new document created in a CoRAL document, should I also return the location options or should they be omitted?

Again, the section isn't intended to say how you're supposed to
indicate the URL of a new resource. Just what the meaning of a CoRAL
document in the response to a POST is :-)

Maybe some sort of style guide for CoRAL-based applications would be
useful, giving recommendations such as whether to prefer the CoAP
Location-* options or the payload for indicating the URL of a newly
created resource.

> Section 6.1.3 – I am wondering if an application might also require that the links and forms in a document be encoded in a specific order?

That's a good question. My first reaction would be that that might be
overly restrictive. But maybe if that leads to measurable improvements
in code size or so, it might be worth considering. Do you perhaps have
an illustrative example?

> I skimmed the end of the document so I may do another pass on that section later.

Thanks!

Klaus