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

[Jim Schaad <[e-mail]>]

-----Original Message-----
From: Klaus Hartke <[e-mail]> 
Sent: Tuesday, June 9, 2020 2:00 AM
To: Jim Schaad <[e-mail]>
Cc: [e-mail]; [e-mail] WG <[e-mail]>
Subject: Re: [core] Review of draft-ietf-core-coral-03

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."?
[JLS] Yes that works.

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

[JLS] Neither of these need to have timezones handled, both of these are designed to be timezone free.  If we have a meeting, it starts at a specific instance in time and thus having us agree on that instance even if we are in different timezones is of importance.  However, my birthday occurs on a specific date and the time in that date is no longer of relevance.  You can wish me happy birthday at any point on that date (and no it is not my birthday today).  Don't have a use for TimeOfDay off the top of my head, but again it is not a specific instance in time so timezones do not apply.

> 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?
[JLS] I don't know if there is one.  An empty payload could of course be done.  The question just popped into my mind and I wanted to make sure that GET was the only one that would be used here.

> 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?
[JLS] You cannot solve the problem with IRIs and there is no way that you can try.  However there is no reason to make the problem worse by allowing identifiers to have this problem.  

> 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 :-)

[JLS] OK - I don't think this needs to change I was just making sure.

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

[JLS] I would be happy if this was part of the application document rather than here.

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

[JLS] First I want to be clear that I think this would be application specific.  But if you are looking for some specific links and all of the forms are at the end then you can stop the blockwise transfer earlier.  That was what I was thinking when I wrote the question.

Jim


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

Thanks!

Klaus