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

Erik Auerswald <auerswal@unix-ag.uni-kl.de> Thu, 18 April 2024 05:25 UTC

Return-Path: <auerswal@unix-ag.uni-kl.de>
X-Original-To: art@ietfa.amsl.com
Delivered-To: art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9A55C151061 for <art@ietfa.amsl.com>; Wed, 17 Apr 2024 22:25:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6bMQ0l7AAUQ for <art@ietfa.amsl.com>; Wed, 17 Apr 2024 22:25:31 -0700 (PDT)
Received: from mailgw1.uni-kl.de (mailgw1.uni-kl.de [IPv6:2001:638:208:120::220]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91B8FC14CE4A for <art@ietf.org>; Wed, 17 Apr 2024 22:25:30 -0700 (PDT)
Received: from sushi.unix-ag.uni-kl.de (sushi.unix-ag.uni-kl.de [IPv6:2001:638:208:ef34:0:ff:fe00:65]) by mailgw1.uni-kl.de (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id 43I5Ph7a151529 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 Apr 2024 07:25:43 +0200
Received: from sushi.unix-ag.uni-kl.de (ip6-localhost [IPv6:::1]) by sushi.unix-ag.uni-kl.de (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id 43I5PQ74031570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 18 Apr 2024 07:25:26 +0200
Received: (from auerswal@localhost) by sushi.unix-ag.uni-kl.de (8.14.4/8.14.4/Submit) id 43I5PQZW031567; Thu, 18 Apr 2024 07:25:26 +0200
Date: Thu, 18 Apr 2024 07:25:26 +0200
From: Erik Auerswald <auerswal@unix-ag.uni-kl.de>
To: Donald Eastlake <d3e3e3@gmail.com>
Cc: ART Area <art@ietf.org>
Message-ID: <20240418052526.GA24663@unix-ag.uni-kl.de>
References: <171332687483.30286.1243519720062169998@ietfa.amsl.com> <CAF4+nEHk2_OPS8-G9m+wFMKU0gqjWp8W8CAfkjG7iHOz=7nFCQ@mail.gmail.com> <20240417112059.GA10771@unix-ag.uni-kl.de> <CAF4+nEGsZq0MuDce0iuA0u-Shu_NnXNhUo94kAZavc20D0M=7A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAF4+nEGsZq0MuDce0iuA0u-Shu_NnXNhUo94kAZavc20D0M=7A@mail.gmail.com>
Author: Erik Auerswald <auerswal@unix-ag.uni-kl.de>
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/FYlob5zDfhVD5D2il2QoeQKDWgc>
Subject: Re: [art] Fwd: New Version Notification for draft-rivest-sexp-06.txt
X-BeenThere: art@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/art>, <mailto:art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art/>
List-Post: <mailto:art@ietf.org>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/art>, <mailto:art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Apr 2024 05:25:33 -0000

Hi Donald,

On Thu, Apr 18, 2024 at 12:27:25AM -0400, Donald Eastlake wrote:
> On Wed, Apr 17, 2024 at 7:21 AM Erik Auerswald
> <auerswal@unix-ag.uni-kl.de> wrote:
> > 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.

The point I was trying to make is: there are two different but equivalent
"canonical" (i.e., supposedly unique) S-expressions for any value using
the default display hint.  Two is more than one.  This is not unique.

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

An S-expression 10:helloworld could be saved in a file or sent via
network connection.  Thus one application may have created it, another
may read it.  If the applications use different display hints, one might
see it as text, the other as an image.

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

Like a new application working with saved data from an old application,
or a new application attemtping to interoperate with an old application.
Or perhaps S-expressions are intended for internal application use only?

A user might try to read an S-expression saved years ago on a new system
that does not support the old application, so they might need to use a
different application.

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

IMHO S-expressions are completely different from netstrings.  Netstrings
and S-expressions have different goals and different properties.
Some simple S-expressions are valid netstrings, and netstrings may
be valid S-expressions (depending on the default display hint and the
contents of the netstring).  So there is opportunity for confusion.

Best regards,
Erik