Re: [Uri-review] Review Provisional registration for app URI scheme

Carsten Bormann <cabo@tzi.org> Wed, 17 January 2018 17:42 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: uri-review@ietfa.amsl.com
Delivered-To: uri-review@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F330912D887 for <uri-review@ietfa.amsl.com>; Wed, 17 Jan 2018 09:42:16 -0800 (PST)
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, 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 ffPJkZ_Ik8Ac for <uri-review@ietfa.amsl.com>; Wed, 17 Jan 2018 09:42:15 -0800 (PST)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 4F82F12AAB6 for <uri-review@ietf.org>; Wed, 17 Jan 2018 09:42:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w0HHgBkd015004; Wed, 17 Jan 2018 18:42:11 +0100 (CET)
Received: from [192.168.217.114] (p5DC7EAF5.dip0.t-ipconnect.de [93.199.234.245]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3zMDtV6jv9zDWrt; Wed, 17 Jan 2018 18:42:10 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <CAMBJEmU2s8B8Rvz-GW=3n4Dt0c_qCQHzm1M52GpAXn+qQmHzvw@mail.gmail.com>
Date: Wed, 17 Jan 2018 18:42:10 +0100
Cc: Julian Reschke <julian.reschke@gmx.de>, uri-review@ietf.org
X-Mao-Original-Outgoing-Id: 537903728.945443-2b321e3da98eac7e24da8e8b43297f50
Content-Transfer-Encoding: quoted-printable
Message-Id: <AFAEFB6C-CD3E-4BD1-B1B5-35E9749D45FC@tzi.org>
References: <20180117144647.GC5245@biggie> <4d910f73-9ca4-c661-0ff1-f508b8ccbed2@gmx.de> <FCE36985-BDC4-419E-97AB-CC061B43A9C7@tzi.org> <CAMBJEmU2s8B8Rvz-GW=3n4Dt0c_qCQHzm1M52GpAXn+qQmHzvw@mail.gmail.com>
To: Stian Soiland-Reyes <stain@apache.org>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/uri-review/OKprfORtJ0ZHAalksIqxzUiSwEU>
Subject: Re: [Uri-review] Review Provisional registration for app URI scheme
X-BeenThere: uri-review@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Proposed URI Schemes <uri-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uri-review>, <mailto:uri-review-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/uri-review/>
List-Post: <mailto:uri-review@ietf.org>
List-Help: <mailto:uri-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jan 2018 17:42:17 -0000

On Jan 17, 2018, at 17:46, Stian Soiland-Reyes <stain@apache.org> wrote:
> 
> On 17 January 2018 at 16:38, Carsten Bormann <cabo@tzi.org> wrote:
> 
>> … which raises the question what “app” stands for.
>> The draft talks about archives and packages, which explains “a” and the first “p”, but I don’t understand the second “p” (pointer?).
>> Yes, I read about the desire to stay compatible with https://www.w3.org/TR/2015/NOTE-app-uri-20150723/, but it probably would help to have a more accurate retronym if that is necessary.
> 
> +1 to make a good bacronym :) "Archive and Packaging Protocol”?

Maybe better: "Archive or Package internal Pointer"?

> But.. I deliberately left out a protocol unless
> https://rawgit.com/stain/I-D/master/app/app.html#rfc.section.3.1
> counts?

Right, protocol is probably misleading.

>> (I’m interested in this as it is sometimes useful to have URIs for references from a CBOR data item to other data items within a bigger, compound data item.  We could define this based on this scheme or in a different way, possibly based on the way the compound data item is formed.)
> 
> Interested in your requirements here, specially if you need more
> flexibility in the authority or path field. I guess this will fit into
> the comments on the Internet-Draft -- but feel free to do Pull
> Requests before that ! :)

I haven’t put much thought into the general problem yet, but this sounds like a neat piece of research to engage in.
(But probably not on this list.  We have T2TRG for that...)

Grüße, Carsten