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

[Klaus Hartke <[e-mail]>]

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.

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

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

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

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

    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