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

From: Jim Schaad <[email-masked]>
Date: Sat, 11 Jan 2020 21:03:48 -0800

Klaus,

The change of text by adding the last paragraph of section 3.1.1 took me by
surprise.  It does not match what my understanding of how things are going
to be parsed.  It took me quite a while to realize that there is a set of
conflicting statements here.  To me, the text appears to state that when
parsing  document there is a single environment, and that environment
consists of two variables.  However, when parsing a link or a form there is
a new pair of variables that are added to this environment.  Thus in my mind
the environment consists of a stack of variable pairs not just a single pair
of variables.

Section 3.2.1 - There is a MUST NOT in the last paragraph, is the receiver
of a document supposed to enforce this in some manner if it is in a location
that it does not currently care about.  Some things can be checked such as
an integer where a text string is required, but for form fields this would
seem to be not generally enforceable.

Section 4.2.3.3 - I think I might be missing some restrictions here and want
to verify.  Consider the following document:

#using a = <http://coapapp.org/app1>

a:2#tag </tos>

In this case, is the result of the processing
<http://coapapp.org/app12#tag>?  

Jim

---

From: Klaus Hartke <[email-masked]>
Date: Sun, 12 Jan 2020 12:26:28 +0100

> the environment consists of a stack of variable pairs not just a single pair

In draft-ietf-core-coral-02, the environment consists of the two
variables, but each scope creates a new environment that is discarded
at the end of the scope. So, yes, there's a stack of environments
involved, not just a single environment. (This hasn't changed since
draft-hartke-t2trg-coral-03.)

The idea behind this is that a processor should be able to skip over
an entire sub-tree without having to process all the directives in it.
Before CoRAL used CBOR, each sub-tree used to be prefixed by its
number of bytes rather than its number of data items, so skipping over
a sub-tree could be implemented by simply bumping a pointer and doing
a bounds check.

> seem to be not generally enforceable.

The intention here was to say that the MUST NOT applies to data types
that are syntactically not allowed (like a Boolean as a link relation
type) but not to data types that are semantically not allowed (like a
Boolean as a form field value that is supposed to indicate a content
format).

> <http://coapapp.org/app12#tag>?

According to the ABNF in section 4.1, the second line would tokenize as

  identifier("a") punctuator(":") integer(2)
        punctuator("#") identifier("tag") iriref("/tos")

Section 4.2.3.3 requires two identifiers separated by a colon, so this
line is currently a syntax error.

If you, for example, have

    a:b2 </tos>

instead, the second line would tokenize as

   identifier("a") punctuator(":") identifier("b2") iriref("/tos")
   \______________________________________________/
                    qualified-name
   \______________________________________________/ \____________/
                          IRI                             IRI
   \______________________________________________/ \____________/
                    relation-type                     link-target
   \_____________________________________________________________/
                              link

and the result of processing a:b2 would be <http://coapapp.org/app1b2>.

Best regards,
Klaus

---

From: Jim Schaad <[email-masked]>
Date: Sun, 12 Jan 2020 09:30:29 -0800

-----Original Message-----
From: Klaus Hartke <[email-masked]> 
Sent: Sunday, January 12, 2020 3:26 AM
To: Jim Schaad <[email-masked]>
Cc: [email-masked]; [email-masked] WG <[email-masked]>
Subject: Re: [core] Review of draft-ietf-core-coral -02

Jim Schaad wrote:
> The change of text by adding the last paragraph of section 3.1.1 took 
> me by surprise.  It does not match what my understanding of how things 
> are going to be parsed.  It took me quite a while to realize that 
> there is a set of conflicting statements here.  To me, the text 
> appears to state that when parsing  document there is a single 
> environment, and that environment consists of two variables.  However, 
> when parsing a link or a form there is a new pair of variables that 
> are added to this environment.  Thus in my mind the environment 
> consists of a stack of variable pairs not just a single pair of variables.

In draft-ietf-core-coral-02, the environment consists of the two variables, but each scope creates a new environment that is discarded at the end of the scope. So, yes, there's a stack of environments involved, not just a single environment. (This hasn't changed since
draft-hartke-t2trg-coral-03.)

The idea behind this is that a processor should be able to skip over an entire sub-tree without having to process all the directives in it.
Before CoRAL used CBOR, each sub-tree used to be prefixed by its number of bytes rather than its number of data items, so skipping over a sub-tree could be implemented by simply bumping a pointer and doing a bounds check.

[JLS] What changed is not how things work, but the specific text that was added to section 3.1.1 - that is the text that got me confused short term.

> Section 3.2.1 - There is a MUST NOT in the last paragraph, is the 
> receiver of a document supposed to enforce this in some manner if it 
> is in a location that it does not currently care about.  Some things 
> can be checked such as an integer where a text string is required, but 
> for form fields this would seem to be not generally enforceable.

The intention here was to say that the MUST NOT applies to data types that are syntactically not allowed (like a Boolean as a link relation
type) but not to data types that are semantically not allowed (like a Boolean as a form field value that is supposed to indicate a content format).

[JLS] Could be clearer.   

> Section 4.2.3.3 - I think I might be missing some restrictions here 
> and want to verify.  Consider the following document:
>

Section 4.2.3.3 requires two identifiers separated by a colon, so this line is currently a syntax error.

    a:b2 </tos>

[JLS] I should have looked at the ABNF, sorry about that.  I don't believe that there is any way to use this with <http://coapapp.org/app12#Hi%20Mom> but I don't think that is a real problem.

Jim

Best regards,
Klaus

---

From: Klaus Hartke <[email-masked]>
Date: Sun, 12 Jan 2020 18:54:25 +0100

>> type) but not to data types that are semantically not allowed (like a Boolean as a form field value that is supposed to indicate a content format).

I've made an attempt for a small clarification here:
<https://github.com/core-wg/coral/commit/e851af62bed6c1a4e07d8811f7f0e4163abde548>.
If you think that can be further improved, a pull request would be
very welcome :)

Klaus