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
- [core] HREF compression encoding Jim Schaad
- Re: [core] HREF compression encoding Carsten Bormann
- Re: [core] HREF compression encoding Thomas Fossati
- Re: [core] HREF compression encoding Jim Schaad
- Re: [core] HREF compression encoding Christian Amsüss
- Re: [core] HREF compression encoding Jim Schaad