Re: [art] Fwd: New Version Notification for draft-rivest-sexp-06.txt

[Donald Eastlake <[e-mail]>]

Hi Erik,

On Wed, Apr 17, 2024 at 7:21 AM Erik Auerswald
<[e-mail]> wrote:
>
> Hi,
>
> On Wed, Apr 17, 2024 at 01:02:54AM -0400, Donald Eastlake wrote:
> >
> > An improved version has been posted responding to many of the comments
> > that have been made.
>
> Thanks for the update!
>
> I'd like to make a few comments from a quick glance:
>
> 1. It seems to me as if the second example of an S-expression given in
>    section 6.1 does not match the ABNF given in section 7.1.

See Marc's response.

> 2. It seems to me as if the "canonical" representation is not uniquely
>    defined, because -- according to the examples -- it may use "display
>    hints", but it is not specified if the "default" display hint
>    ("application/octet-stream" in the current draft) may be given or not.

Sure the default display hint can be given. Basically, every octet
string either has a display hint or not. If it does not, it may be
interpreted as if it had the default display hint. But the default
display hint is not suppressed just because it is the default nor is
it actually added if an octet string has no display hint.

> 3. Since the "default" display hint may be application-specific, omitting
>    it from the "canonical" representation, as shown in two of the three
>    examples in section 6.1, seems to possibly change the "canonical"
>    S-expression value when changing applications.

I don't think so. As above, the display hint is either present or not
in the S-expression. If it is present, whether it is the default
display-hint or some other display-hint, then it appears in the
canonical representation. If it is not present, it does not appear in
the canonical representation.

> 4. The value of the "default" display hint has changed over the versions
>    of this draft.  I'd expect this to cause interoperability problems
>    if any new implementation were to emerge, and if any existing
>    implementation would already implement the original default display
>    hint.

If you were sending an S-expression including an octet-string that
does not have a display hint from an application/implementation where
that string has one default display-hint to an
application/implementation where it will have a different default
display hint and this actually makes a difference, then there might be
a problem. So don't do that.

> 5. I'd say that this S-expression format has no similarities to
>    Bernstein's "netstrings", i.e., the length of a general S-expression
>    is not given up front.  Giving the complete length up front is the
>    one special property provided by netstrings.  Thus I'd say that the
>    last sentence of the first paragraph of section 1.1 is misleading.

Well, it seems to me that "similar" is mostly in the eye of the
beholder. Do you disagree with the rest of that sentence, that
S-expressions are more "readable and flexible" than net-strings?

> Best regards,
> Erik