Re: [core] HREF compression encoding

Jim Schaad <ietf@augustcellars.com> Mon, 25 May 2020 16:34 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 257333A0AD6 for <core@ietfa.amsl.com>; Mon, 25 May 2020 09:34:03 -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 9yVD5btBdBfF for <core@ietfa.amsl.com>; Mon, 25 May 2020 09:34:00 -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 968FF3A0ADA for <core@ietf.org>; Mon, 25 May 2020 09:33:59 -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; Mon, 25 May 2020 09:33:34 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: 'Christian Amsüss' <christian@amsuess.com>, 'Klaus Hartke' <klaus.hartke@ericsson.com>
CC: core@ietf.org
References: <00ba01d618d2$bc689e60$3539db20$@augustcellars.com> <C2189FF3-2DD2-41E3-9719-789A982E0405@tzi.org> <03cc01d623b4$8283a7c0$878af740$@augustcellars.com> <20200511112123.GA2573363@hephaistos.amsuess.com>
In-Reply-To: <20200511112123.GA2573363@hephaistos.amsuess.com>
Date: Mon, 25 May 2020 09:33:32 -0700
Message-ID: <02fb01d632b2$3cac7170$b6055450$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
Thread-Index: AQF3IyvGSPj7FWkIh2hLJEkWXqN4kAM3xeaGAg7FgjkBLObeFKlCsllA
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/-ivUV5vnfFMfUkqOQnY-_B7ixlA>
Subject: Re: [core] HREF compression encoding
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: Mon, 25 May 2020 16:34:04 -0000

For some reason I was thinking about the issue of what should be the default
marker value.  While doing so I realized that I had been stuck in a train of
thought guided by the text version of decomposing URIs and it does not
really apply for this encoding.

Consider the URI "coap://localhost/a/b/c", in text one could decompose this
as "coap://localhost" and "/a/b/c" representing this as
[ "coap", "localhost"]   [ABSOLUTE, "a", "b", "c"]

However, this could just as easily be represented as
["coap", "localhost"] [APPEND, "a", "b", "c"]

I therefore propose the following as a list of usual things:

1.  Absolute URIs with and without having a predefined scheme:  The former
needs no leading marker and the latter would need a marker that it is a
schema.  
2.  Base URI of authority and relative URI of absolute path:  As noted above
this can use the append marker or absolute path marker.
3.  Base URI of authority + path and relative URI of absolute path:  Needs
an absolute path maker.
4.  Base URI of authority + path with implicit end path segment  and
relative URI:  ("http://localhost/a/" and "b/c") Can use the append marker
5.  Base URI ending in a "file name" path segment and relative URI:
("http://localhost/a/home.html" and "./b/c") This needs to use the Up One
marker.
6.  Base URI ending in a path segment where there is no difference between
last and intermediate names and a relative URI: ("coap://localhost/a" and
"./a/b/c") Can use the append marker while omitting the first path segment
of the relative path ([APPEND, "b", "c"])

I think that if we combine group 2 and group 6, this will be far more
prevalent than group 5 would be for the IoT world and potentially in
general.  I have used both 3 and 5 for html but don't ever use 5 for coap.
The use of 2 and 6 are going to be the most common for both .well-known/core
and a resource directory (which is allowed to control both the base URI and
the relative URI).

Jim


-----Original Message-----
From: Christian Amsüss <christian@amsuess.com> 
Sent: Monday, May 11, 2020 4:21 AM
To: Jim Schaad <ietf@augustcellars.com>
Cc: 'Carsten Bormann' <cabo@tzi.org>; core@ietf.org
Subject: Re: [core] HREF compression encoding

Hello,

> This is an interesting proposal.

I like that too.

> [JLS] [...] An RD is going to be heavily into absolute paths.

Even that depends on how the RD is used. When querying for resources of a
specific type across a network, it will largely consist of one full CRI
([COAP, ...]) for the anchor and one relative ([PATH-..., ...]) for the
target. Queries that yield multiple records from the same server can make
use of CoRAL's base directive.

Kind regards
Christian

--
To use raw power is to make yourself infinitely vulnerable to greater
powers.
  -- Bene Gesserit axiom