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

From: Jim Schaad <[email-masked]>
Date: Sun, 7 Jun 2020 20:09:52 -0700

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/

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

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

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

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

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

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

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?

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?

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?

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

Jim

---

From: Klaus Hartke <[email-masked]>
Date: Tue, 9 Jun 2020 11:00:03 +0200

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 t…

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…

(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

---

From: Jim Schaad <[email-masked]>
Date: Tue, 9 Jun 2020 08:03:36 -0700

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

Hi Jim,

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

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.

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.

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

Thanks!

Klaus

---

From: Jim Schaad <[email-masked]>
Date: Thu, 11 Jun 2020 11:02:55 -0700

I made a mistake - the CBOR group is defining two new date tags but not a time of day tag.

-----Original Message-----
From: core <[email-masked]> On Behalf Of Jim Schaad
Sent: Tuesday, June 9, 2020 8:04 AM
To: 'Klaus Hartke' <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [core] Review of draft-ietf-core-coral-03

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

Hi Jim,

Fixed.

Jim

Thanks!

Klaus

_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core