Re: [core] Ordering question for draft-hartke-t2trg-coral

Jim Schaad <ietf@augustcellars.com> Thu, 08 August 2019 20:35 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF5D61200A3; Thu, 8 Aug 2019 13:35:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRBL9ggtx2re; Thu, 8 Aug 2019 13:35:17 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6966120198; Thu, 8 Aug 2019 13:35:00 -0700 (PDT)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 8 Aug 2019 13:34:55 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: 'Klaus Hartke' <hartke@projectcool.de>
CC: draft-hartke-t2trg-coral@ietf.org, core@ietf.org
References: <000201d54d40$57609210$0621b630$@augustcellars.com> <CAAzbHvbwRb4QEU4eiv5R9goZpCdmqY9d_byJ6xR8ngSHxQfK1A@mail.gmail.com>
In-Reply-To: <CAAzbHvbwRb4QEU4eiv5R9goZpCdmqY9d_byJ6xR8ngSHxQfK1A@mail.gmail.com>
Date: Thu, 08 Aug 2019 13:34:53 -0700
Message-ID: <00e701d54e28$bd7557a0$386006e0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQOAnuT8wet3nmU3+ngvZ7va+KB/6QJo9Jf6o4fGDhA=
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/lj7WwfjVxJDmvsJm8ZQdP2145V4>
Subject: Re: [core] Ordering question for draft-hartke-t2trg-coral
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Aug 2019 20:35:20 -0000

Klaus,

Some responses in line.  This was the problem I was thinking about as a dictionary in my pubsub node would be an easier way to access the values.  But if order is important then that will not work.

jim

-----Original Message-----
From: Klaus Hartke <hartke@projectcool.de> 
Sent: Thursday, August 8, 2019 3:22 AM
To: Jim Schaad <ietf@augustcellars.com>
Cc: draft-hartke-t2trg-coral@ietf.org; core@ietf.org WG <core@ietf.org>
Subject: Re: [core] Ordering question for draft-hartke-t2trg-coral

Hi Jim,

> In the process of working on this, I am trying to determine if there 
> is a real ordering to the items in a document or not.  The only reason 
> that I can see for having one is the possibility directives change the current context.
> If one stores all of this as absolute paths (or relative to a known 
> point), one could synthesis the base directive on the fly when doing 
> serialization and thus the order of links and forms would not be significant.

in the serializations, elements clearly have an order on the wire, and the meaning of each elements depends on the current processor state ("current context") that changes based on the directives processed so
far:

    #base <coap://foo.example/>
    quux </1>
    #base <coap://bar.example/>
    quux </2>

is not equivalent to

    #base <coap://foo.example/>
    quux </2>
    #base <coap://bar.example/>
    quux </1>

[JLS] In terms of the base directive, this does not bother me because I would do the normalization as part of the parsing process.  I am worried that somebody may come up with a new directive for which this would not be the case.  New directives can also cause problems in the future because how do I deserialize an object when I find a directive I don't understand.

In the data model, the question is valid whether a link `quux <coap://foo.example/1>` followed by a link `quux <coap://bar.example/2>` is semantically equivalent to the link `quux <coap://bar.example/2>` followed by the link `quux
<coap://foo.example/1>`:

Is

    #base <coap://foo.example/>
    quux </1>
    #base <coap://bar.example/>
    quux </2>

equivalent to

    #base <coap://bar.example/>
    quux </2>
    #base <coap://foo.example/>
    quux </1>

?

This question is currently left open in draft-hartke-t2trg-coral-09.
I'd say the answer mostly depends on the semantics of the link relation types. E.g.,:

* a link to the mother of a person followed by a link to their father is probably equivalent to a link to their father followed by a link to their mother;
[JLS] Right, these can be considered to be completely independent items.

* a link to a resource with sz 100 followed by a link to a resource with sz 50 is probably not equivalent to a link with sz 50 followed a link with size 100 if the client requests the links be sorted by sz;
[JLS] But in this case, you are talking about having the items sorted at the time it is serialized.  So in this case you are actually asking for the order to be changed from the original one to a new order.  If this causes other unintentional order changes that would cause a problem.

* a link to a resource with ct Link-Format followed by a link to a resource with ct CoRAL is probably not equivalent to a link with ct CoRAL followed by a link with ct Link-Format if the server wants to express that the CoRAL alternative should be preferred.
[JLS] This one kind a begs the question should a multivalued link be setup as an array of values rather than something that the client could accidently change the of order if it does not expect to have multiple values.  In that case it would presumable get the last value which would be wrong.  I realize that having an array of values gives a problem because that is also what a ciri looks like and there would need to be a way to distinguish them.

Klaus