From nobody Mon Jun 26 05:59:18 2017 Return-Path: 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 BCC75129B5B; Mon, 26 Jun 2017 05:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-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 ExvyYyaGB761; Mon, 26 Jun 2017 05:59:15 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9E4F129B57; Mon, 26 Jun 2017 05:59:14 -0700 (PDT) Received: from [192.168.178.20] ([93.217.84.68]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MKYpv-1dQqed1hI7-001zV5; Mon, 26 Jun 2017 14:59:12 +0200 From: Julian Reschke To: IETF Discussion , art@ietf.org References: Message-ID: Date: Mon, 26 Jun 2017 14:59:11 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:1kNNqodrTRMO+V676Dz5f4dqM0Txwkoaa1Eevm1EF48ryEI/Phz FsCp/sKLA7wPfjYyv9Mfp4XX8p9Cku0gbxeYzQy2yeV7voBtmm1jdNV4eACg1S3VaZHxGPH rAexX80VthENJxboOFmzHhowgcmbJLLDw1/eidl6CmV7HeZNszypHUj6TJHEJjyimRuCU0K QG0I5XJb1xC7LMG7Oz5FA== X-UI-Out-Filterresults: notjunk:1;V01:K0:gPDQu/1ee2o=:8wZRx6wZfwRHSmQIU3TKFy yiIC7opYazgqEd7zEIiYPATXwmZW2c7VQ7unryKL/VN5NfMpuBLeeEM/LKjdxicuXZkGpYOE+ ZrKugma2Ubg3Ldwm2JJ/fHMgn2owjBb/WejmNr/8JQ2ydSG2aXHd21J9Q+E2VF3+yraSQqKRj SCWymducSADs99swj8HBcSwFGeC2JVXztQMfALyFoTkXOdlkoUD562jYpWcZlBe1UT6AXG5n6 UPIm+5FmdI/G7tnejkwqqtY9Qt5au1HVCzgqriY4m8MrMwYTyrGRlxH0yRxSgwO09rcJ1BtU+ RKlRucvHTMkiI76Ix5oHKpfUAnGniuXD8eVEp7j1w3NeCbyYyWFo0s/3lOvOpLEkxPsNQjREO ReObibiwKIcOadxYfvXoCXynaGMadUsotFLyiXiD5Bcjmertw5tu8zf7ZIb97nhP/6h/NgnJK rDlrxi+pZe/s6qwjfoG0SCPHghxmlRybBdqklwG7VtLDIkkwY1B4DlfYFrY2192Jm+dTMHexk 7KZvSFYwbIUZNWGmTvsaC5Ju8r3Yq8VnYFC0zRvgYO9e+C2y1VbH1+eG6OvHn5pQK38ok3lsB EmCK/SMnmRj+mo+eG4BGZ3No6SVTLe1IJdmUUy+MLnY5WLPWK0Z89iUcy4nXVC9yBtQ2LGJIY vLMHelEcOwthjQoqwO3H4ltCTBeWiBbWEHesCo+KLX7CDYllNTqYxTxaEKiRkIAlLfOsHpfQk x5gC30jtcxZcE4llL+shUpqSAmPBtTLy0YtaBidBH9g9at4hs/uerPOEBp7/uO1tNxkuF1s0m viEY+fj Archived-At: Subject: Re: [art] ART Area Review for draft-ietf-calext-caldav-attachments-02 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 12:59:17 -0000 On 2017-05-14 16:23, Julian Reschke wrote: > ... Another thing that I just noticed: the spec uses Content-Disposition as request header field (), however it's currently only defined as response header field (RFC6266). Best regards, Julian From nobody Mon Jun 26 14:29:58 2017 Return-Path: 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 94A28129B19 for ; Mon, 26 Jun 2017 14:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com 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 9ut2_6fGBDhU for ; Mon, 26 Jun 2017 14:29:56 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B644129AF4 for ; Mon, 26 Jun 2017 14:29:56 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id 9F5906000509; Mon, 26 Jun 2017 14:29:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:mime-version:content-type; s= cryptonector.com; bh=WKTxr/Ifi/f8OYee4GH52XAR/n8=; b=SLUVxySKf2V YckNeyc/2sJCp2Zhx13SVqtaXoiUwdGuGOwRLbqE+Znim4JUXevTpvKxeK5VwrVM 0xaCWj4Rl6sO+VK63WGeoqdsZwtJMpKuK0Eif889QOxjr+FOibdSXrnmNnVcGzuw //Nos4ejxZ++Pg1+o1HRhox7g/MyOGcs= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTPSA id 54F8B6000504; Mon, 26 Jun 2017 14:29:55 -0700 (PDT) Date: Mon, 26 Jun 2017 16:29:52 -0500 From: Nico Williams To: art@ietf.org Message-ID: <20170626212951.GA3422@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: [art] Software URNs for dependency representation X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 21:29:57 -0000 The following is so obvious (I think!) that I suspect it's been done, or at least discussed. If so, I would appreciate pointers and I apologize for the noise. Suppose you have a build system that lets a recipe refer to dependencies. Well that's very common place, naturally. But, how shall dependencies be identified? In the big wide open Internet the answer is likely to be: URLs. But URLs come with a problem: you might need to change locations (e.g., mirrors). Then you have to edit all your recipes. Worse, you have to edit all the upstream recipes! E.g., you depend on a library that depends on gcc, with that dependency given as a URL to a location you cannot reach (e.g., in an intranet). We need something better than URLs, something like... URNs! urn:software:foo-1.2.3rc1/git/a1b2c3d4... urn:software:foo-1.2.3rc1/git/tag/1_2_3rc1 urn:software:foo-1.2.3rc1/git/tag/1_2_3rc1?default_location= or urn:brew:foo-1.2.3rc1/git/tag/1_2_3rc1 urn:debian:stretch/foo-1.2.3 urn:SomeGitServiceProvider:foo-1.2.3rc1/tag/1_2_3rc1 What needs to be encoded? Here's a few things: - source (not location) This would be the NID of the URN. In the above it's "software", and that's probably not right as you'll see. Vendors/distros/whatever could each have their own, as each may have different location resolution methods. Alternatively we could have a sub-namespace encoded in the NSS of the URN. Having as few namespaces as possible would be nice, but since a name resolution service will be needed, it's reasonable to expect at least a few namespaces. Perhaps Debian might like a namespace per-release. Or perhaps the release would be in the NSS part of the URN as in the above example. Everything else definitely goes in the NSS part of the URN. - name of software, naturally - software version information This might include things like git commit hashes, tag names, ... - perhaps a way to distinguish built "package" from "source" (maybe this should be implied by the namespace) - OPTIONAL: perhaps a query or fragment by which to identify one or more locations for the software This is for things that don't fit into namespaces for any packaging or VCS services. - OPTIONAL: hash of software (e.g., when other versioning information does not provide enough secure version identification information) - OPTIONAL: signature(s) Signatures could instead be found in the same way as the software, and would be bound by any hash that appears in the URN. Finding locations for software in a relatively small number of namespaces is easy: make it configurable in the software that needs it and provide a default configuration with default locations. These could be listed in an IANA registry, naturally. Location resolution of these sorts of URNs is easy then: first determine if the namespace is supported by the software consuming the URN, and if so then resolve a root location(s) (see above), lastly employ whatever additional resolution the namespace owner specifies. URN namespace registration information could be used to make this location resolution automatically available in all/most cases. Thoughts? Nico -- From nobody Tue Jun 27 11:31:34 2017 Return-Path: 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 1FCC4129C07 for ; Tue, 27 Jun 2017 11:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com 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 6d8TaFk877I3 for ; Tue, 27 Jun 2017 11:31:29 -0700 (PDT) Received: from homiemail-a106.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C618D1243F3 for ; Tue, 27 Jun 2017 11:31:29 -0700 (PDT) Received: from homiemail-a106.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTP id 4D7A430002925; Tue, 27 Jun 2017 11:31:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=gu9ehTVVFGprrn b5mxvtBVZeBEM=; b=RTaxbNctTu0dLrMw/XINA3U2xScRbsnwW7gZdkwIVr3OoS N1PdHs4PIqOM/GpC46mVHS5HTfor+BsFngSAiTDyT1v+1HdIdjM5mgmyoed8XQx6 aEHIaVbkX7N6B08RHhIdkSxF0SgpdHfRR7JOm1Sv8/pGOYqoJxHRFC2I77xFA= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTPSA id F1F7230002924; Tue, 27 Jun 2017 11:31:28 -0700 (PDT) Date: Tue, 27 Jun 2017 13:31:26 -0500 From: Nico Williams To: Graham Klyne Cc: art@ietf.org Message-ID: <20170627183125.GL3432@localhost> References: <20170626212951.GA3422@localhost> <5952980E.60707@ninebynine.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5952980E.60707@ninebynine.org> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [art] Software URNs for dependency representation X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 18:31:32 -0000 On Tue, Jun 27, 2017 at 06:38:22PM +0100, Graham Klyne wrote: > On 26/06/2017 22:29, Nico Williams wrote: > >But, how shall dependencies be identified? > > > >In the big wide open Internet the answer is likely to be: URLs. > > Strictly, I'd say *on the Web* the answer is URLs (aka URIs). The Internet > could and does use all sorts of identifiers. Well, sure, if we must have URLs then a new URI scheme would be needed. > >But URLs come with a problem: you might need to change locations (e.g., > >mirrors). Then you have to edit all your recipes. Worse, you have to > >edit all the upstream recipes! > > Well, it depends on the kind of URI that you use. There are some that are > location-independent (e.g. uuid:, ni:). > > URNs are URIs too! Yes, quite. > Or even with HTTP URIs, they may be primarile identifiers (e.g. DOIs via > http://dx.doi.org, or PURLs via purl.org). In the Web community, it's a > well-used pattern to use purl.org (aka PURLs) for identifiers where the > primary domain may be insufficiently stable. (There's also another > initiative, w3id, or something like that). These solutions all depend on > introducing a level of indirection (so probably sub-optimal for active > protocol, use), and one still depends to some extent on the redirecting > intermediary. I think those are, indeed, all sub-optimal for this. > URNs might be a good solution for what you propose. But an advantage of > using http URIs for identifiers is that it is possible (in principle) to > dereference them to learn more about the thing identified (the "follow your > nose" principle). If dereferencing is required (and yeah, it probably would be) then a new URI scheme is needed. > Finally, Zenodo (under auspices of CERN IIRC) operate a GitHub-integrated > redirection service for DOIs (and hence http://doi.org URIs) that can be > registered for software. E.g. http://doi.org/10.5281/zenodo.582881 is an > identifier for a version of some software I'm working on. > > Maybe DOIs are an answer you could use? What I had in mind was that you use the URN's NID to lookup a base URI (URL) and append the URN's NSS to the local part in order to obtain an actual URI that can be dereferenced. A new URI scheme seems better, yes. Something like: sw://debian.example/stretch/foo-1.2.3 The authority would be the name of a repository as a domainname, and the local part is... local to whatever base URIs published in DNS for the authority. > You provide a list of details to be "encoded" in a URI. Identifiers don't > really work that way: they name, not encode. The point here is that if you > have to know a bunch of details and an assembly rule to construct a URI, > it's not really working as a URI, more like a URI-like syntax for encoding > stuff. I suspect that what you really need is to be able to generate > different identifiers for any variation of the various variables you > mention. Well, semantically the details are "encoded" in the name. I did not mean to imply that there would be a specific way to construct a name from such details, though I probably did accidentally imply that. > Finally, I'll note that there was some work a while ago for URN (and > arbitrary URI) resolution, going by the name of DDDS: see > https://tools.ietf.org/html/rfc3401 and friends. I'll take a look. Thanks, Nico -- From nobody Tue Jun 27 11:41:46 2017 Return-Path: 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 3DC3F1292F5 for ; Tue, 27 Jun 2017 11:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gbiv.com 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 vmjonS5YNKmt for ; Tue, 27 Jun 2017 11:41:41 -0700 (PDT) Received: from homiemail-a50.g.dreamhost.com (sub5.mail.dreamhost.com [208.113.200.129]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A570E12741D for ; Tue, 27 Jun 2017 11:41:41 -0700 (PDT) Received: from homiemail-a50.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a50.g.dreamhost.com (Postfix) with ESMTP id 2D38D801A412; Tue, 27 Jun 2017 11:41:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=7payB4vUjp9KUPDFYUR7Nt2HDzU=; b=skmbKTX+MS1V4av8qvTGfiA8dirt R5HF2hUGkJopQ4Gk43DdveLHShFsIrUWcOltMDoGzsCumDG9o+vngyJlEz5cB9cP 23EdN1BYndQAu80vo1odPpscYwploQ+jxxyFemx4xa/UTK8g14ckTu7D86vdKkfJ hZf4BukirZicXS4= Received: from [192.168.1.11] (ip68-228-64-138.oc.oc.cox.net [68.228.64.138]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a50.g.dreamhost.com (Postfix) with ESMTPSA id 13DC8801A433; Tue, 27 Jun 2017 11:41:41 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: "Roy T. Fielding" In-Reply-To: <20170627183125.GL3432@localhost> Date: Tue, 27 Jun 2017 11:41:40 -0700 Cc: Graham Klyne , art@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <22241563-BA06-4125-BFE8-8D8E9114CAEF@gbiv.com> References: <20170626212951.GA3422@localhost> <5952980E.60707@ninebynine.org> <20170627183125.GL3432@localhost> To: Nico Williams X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [art] Software URNs for dependency representation X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 18:41:44 -0000 > On Jun 27, 2017, at 11:31 AM, Nico Williams = wrote: >=20 > On Tue, Jun 27, 2017 at 06:38:22PM +0100, Graham Klyne wrote: >> On 26/06/2017 22:29, Nico Williams wrote: >>> But, how shall dependencies be identified? >>>=20 >>> In the big wide open Internet the answer is likely to be: URLs. >>=20 >> Strictly, I'd say *on the Web* the answer is URLs (aka URIs). The = Internet >> could and does use all sorts of identifiers. >=20 > Well, sure, if we must have URLs then a new URI scheme would be = needed. >=20 >>> But URLs come with a problem: you might need to change locations = (e.g., >>> mirrors). Then you have to edit all your recipes. Worse, you have = to >>> edit all the upstream recipes! >>=20 >> Well, it depends on the kind of URI that you use. There are some = that are >> location-independent (e.g. uuid:, ni:). >>=20 >> URNs are URIs too! >=20 > Yes, quite. >=20 >> Or even with HTTP URIs, they may be primarile identifiers (e.g. DOIs = via >> http://dx.doi.org, or PURLs via purl.org). In the Web community, = it's a >> well-used pattern to use purl.org (aka PURLs) for identifiers where = the >> primary domain may be insufficiently stable. (There's also another >> initiative, w3id, or something like that). These solutions all = depend on >> introducing a level of indirection (so probably sub-optimal for = active >> protocol, use), and one still depends to some extent on the = redirecting >> intermediary. >=20 > I think those are, indeed, all sub-optimal for this. >=20 >> URNs might be a good solution for what you propose. But an advantage = of >> using http URIs for identifiers is that it is possible (in principle) = to >> dereference them to learn more about the thing identified (the = "follow your >> nose" principle). >=20 > If dereferencing is required (and yeah, it probably would be) then a = new > URI scheme is needed. >=20 >> Finally, Zenodo (under auspices of CERN IIRC) operate a = GitHub-integrated >> redirection service for DOIs (and hence http://doi.org URIs) that can = be >> registered for software. E.g. http://doi.org/10.5281/zenodo.582881 = is an >> identifier for a version of some software I'm working on. >>=20 >> Maybe DOIs are an answer you could use? >=20 > What I had in mind was that you use the URN's NID to lookup a base URI = (URL) > and append the URN's NSS to the local part in order to obtain an = actual > URI that can be dereferenced. >=20 > A new URI scheme seems better, yes. Something like: >=20 > sw://debian.example/stretch/foo-1.2.3 >=20 > The authority would be the name of a repository as a domainname, and = the > local part is... local to whatever base URIs published in DNS for the > authority. Hmm=E2=80=A6 = https://dwid-org.github.io/uri/historical/draft-ietf-uri-roy-urn-urc-00.tx= t ....Roy From nobody Tue Jun 27 12:20:29 2017 Return-Path: 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 3F9C512969E for ; Tue, 27 Jun 2017 12:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com 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 fpfIWpS2LzD1 for ; Tue, 27 Jun 2017 12:20:26 -0700 (PDT) Received: from homiemail-a105.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7971B1292F5 for ; Tue, 27 Jun 2017 12:20:26 -0700 (PDT) Received: from homiemail-a105.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTP id 0BB0E30002A26; Tue, 27 Jun 2017 12:20:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=VbfLEyvNOv63BBwQ5Lj7xKrWeQo=; b=So4wxIuNYlj xTiLGmFvV+gt+XF5pHHVSrdCJL/yh3C9RBJJwlRpTnZDK4wF6n3UFs4AcRA1t/AA mqiaqATsl9adBMekWiUaEOj/Y+ElDJ6CKaDqJVeNf9QTv/HVqK+vTIRHa0+kN3kW 3g26vkfurBM7bthBlvTnkz8cmJfQPgW4= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTPSA id AC76030002A25; Tue, 27 Jun 2017 12:20:25 -0700 (PDT) Date: Tue, 27 Jun 2017 14:20:23 -0500 From: Nico Williams To: "Roy T. Fielding" Cc: Graham Klyne , art@ietf.org Message-ID: <20170627192022.GM3432@localhost> References: <20170626212951.GA3422@localhost> <5952980E.60707@ninebynine.org> <20170627183125.GL3432@localhost> <22241563-BA06-4125-BFE8-8D8E9114CAEF@gbiv.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <22241563-BA06-4125-BFE8-8D8E9114CAEF@gbiv.com> User-Agent: Mutt/1.5.24 (2015-08-30) Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [art] Software URNs for dependency representation X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 19:20:28 -0000 On Tue, Jun 27, 2017 at 11:41:40AM -0700, Roy T. Fielding wrote: > Hmm=E2=80=A6 >=20 > https://dwid-org.github.io/uri/historical/draft-ietf-uri-roy-urn-ur= c-00.txt Yeah, something like that. I know -I'm certain- that we've had a discussion about this many times in the past. This is really all about how to name things in a way that is location-independent yet dereferenceable. A perennial debate, no? URIs leave it to the scheme to bake in how to dereference. URNs don't deal with automatic deref, though where a URN is more than just a name -- where a URN is a named object that could be retrieved -- then there's generally at least an informal way to dereference. Maybe we should distinguish pure names (e.g., as used in protocol elements, such as OIDs) from named resources and then require a dereference mechanism for the latter. Right now the one mechanism we have for this is defining a new URI scheme. So a new URI scheme it would have to be today, though that is somewhat dissatisfying: there are many URNs that name resources and which could use a deref specification. I'd rather be able name I-Ds and RFCs with URNs and have web software universally be able to dereference those than have to add an rfc: URI scheme to get the same effect. But I'd live with an rfc: scheme, and I'd live with an sw: scheme. DOIs for software were mentioned. But I think with software it's nice to be able to see names and other metadata in the URI, and it's nice to be able to have a very light-weight location resolution algorithm. Yes, yes, we could have every name be a hash or UUID. But URIs have a way of leaking into UIs, so having somewhat human-readable URIs is somewhat handy. (Having a hash as part of a URI is not a problem though.) The location resolution algorithm I have in mind is dead trivial: resolve the location of the base respository, add local part from the URI. The first part can be cached for a long time -- forever even, with cache invalidation only upon failure. The second part is dead trivial. Any location resolution algorithm that requires online infrastructure at all times will probably be very dissatisfying. Thus I oppose the use of DOIs as a primary mechanism for identifying software. Nico --=20 From nobody Tue Jun 27 14:32:55 2017 Return-Path: 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 02BE912EB30 for ; Tue, 27 Jun 2017 14:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 aCwLrmXTf0ah for ; Tue, 27 Jun 2017 14:32:53 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7023B12EB38 for ; Tue, 27 Jun 2017 14:32:52 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id v202so20660117itb.0 for ; Tue, 27 Jun 2017 14:32:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=9VktrRnYfhpeiBy3SHZmce96b3/f5sfKt98R1lKckxU=; b=DWJoFOYg9h3z0e86UQLMtIUkdgbAsMSt5YRVXLkA7a+Bou/jxSHdGC/69vCDWF73GE LdFoO2/0P9RqWzMesy/fbclsu0IpzoB0aCeDqIosT5i90+oT2eQ91wWP7lciwd+QvW0/ c/SjJO51mMi9OyjN+fNDKxzruSXt9EPWDSpQ2YZQxTZFys45qDqwLrcX8uMyL5rWlP39 MP9x2skPTf8lCEZPHUNjS2kFlKHEyVKIEPMa4bpoXZaPOH66dU0tr+sKUYnbV5YU/hqm fVjOMNEzSLSlL4o8/miHTvinoMJGd0mWVVEkW2OjkbJLIsUgxjsbX6HInfP9QC+pe8Oo v71w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=9VktrRnYfhpeiBy3SHZmce96b3/f5sfKt98R1lKckxU=; b=sFMEaERsvjQnfqd8/uU22xt06aLd5dfSJ/W5uQQ0+qu2eBxtL3+0SZVo22Yw120Ly9 sBu5eK3HPopKI5x+8dijo6qyuMEXgUmPru9UDktX6nYJjatdYj8N5mqq2CAb9KC+AMfO dQ4n/EfscgwJ8kHaeU/wgnHxfJvAm0vqZ0hED9JZtAKP8siwH+BGFJNMKe2BGQw2eYod mL/g9HbLDhT/c8PbxO6Vv4pcAj9dlPymuR8ACDwSaJfSgEKJcVoVCJil2Z3c+kiLnWHk hCL6lGz4RSHBJhbDuELlzQ1O+fnn80n2mrCLV+y9eKvhIrg0AlsLJSKFhUh2P96hpRhL sBOg== X-Gm-Message-State: AKS2vOz5skLP9vXKulbXXQ7ATdx111rThYeuke21rQV5S/juI37GvtMF 52MmNz2Wg20KR42dmq5dWKmdyJsKTzZs X-Received: by 10.36.65.23 with SMTP id x23mr5227606ita.2.1498599171724; Tue, 27 Jun 2017 14:32:51 -0700 (PDT) MIME-Version: 1.0 Sender: phluid61@gmail.com Received: by 10.107.20.13 with HTTP; Tue, 27 Jun 2017 14:32:50 -0700 (PDT) Received: by 10.107.20.13 with HTTP; Tue, 27 Jun 2017 14:32:50 -0700 (PDT) In-Reply-To: <20170627192022.GM3432@localhost> References: <20170626212951.GA3422@localhost> <5952980E.60707@ninebynine.org> <20170627183125.GL3432@localhost> <22241563-BA06-4125-BFE8-8D8E9114CAEF@gbiv.com> <20170627192022.GM3432@localhost> From: Matthew Kerwin Date: Wed, 28 Jun 2017 07:32:50 +1000 X-Google-Sender-Auth: wxCQAeK3TB9UCBrv7fAwUSlNlAA Message-ID: To: Nico Williams Cc: Graham Klyne , "Roy T. Fielding" , art@ietf.org Content-Type: multipart/alternative; boundary="001a11c150c24aa9c70552f7cf8a" Archived-At: Subject: Re: [art] Software URNs for dependency representation X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 21:32:55 -0000 --001a11c150c24aa9c70552f7cf8a Content-Type: text/plain; charset="UTF-8" On 28 Jun. 2017 05:21, "Nico Williams" wrote: The location resolution algorithm I have in mind is dead trivial: resolve the location of the base respository, add local part from the URI. The first part can be cached for a long time -- forever even, with cache invalidation only upon failure. The second part is dead trivial. Any location resolution algorithm that requires online infrastructure at all times will probably be very dissatisfying. Thus I oppose the use of DOIs as a primary mechanism for identifying software. Nico -- I think I get what you're saying, but... aren't you literally describing HTTP URLs with DNS names in the authority? Cheers --001a11c150c24aa9c70552f7cf8a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 28 Jun. 2017 05:21, "Nico Williams" <nico@cryptonector.com> wrote:
The location resolution algorithm I have in mind is dead trivial:
resolve the location of the base respository, add local part from the
URI.=C2=A0 The first part can be cached for a long time -- forever even, wi= th
cache invalidation only upon failure.=C2=A0 The second part is dead trivial= .

Any location resolution algorithm that requires online infrastructure at all times will probably be very dissatisfying.=C2=A0 Thus I oppose the use = of
DOIs as a primary mechanism for identifying software.

Nico
--

I think I get what you= 're saying, but... aren't you literally describing HTTP URLs with D= NS names in the authority?

Cheers
--001a11c150c24aa9c70552f7cf8a-- From nobody Tue Jun 27 15:26:17 2017 Return-Path: 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 489CD129B22 for ; Tue, 27 Jun 2017 15:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com 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 rpfAbfhSmJgK for ; Tue, 27 Jun 2017 15:26:13 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ED4812EAF8 for ; Tue, 27 Jun 2017 15:26:13 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id CCBFF9000C33; Tue, 27 Jun 2017 15:26:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=0AaXBuY1BifiSY Gwb/TK/fAD7Ao=; b=WIWpwoF92LJGfwlL/BHHIHfB6PwAga2uf4nATUJQmgwt+/ W4iFWngdcqX86V4esnqcraRL4jkq10ZIhF9fQ9kCa6Drz7KIvSyfT0GkBjQt4LpV b13gP0hr15jko7xVIahNED0RgYCAgQv2PjcjcLisI6XnvMLwP5ltZK87neuc4= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPSA id 5A2249000C31; Tue, 27 Jun 2017 15:26:12 -0700 (PDT) Date: Tue, 27 Jun 2017 17:26:10 -0500 From: Nico Williams To: Matthew Kerwin Cc: Graham Klyne , "Roy T. Fielding" , art@ietf.org Message-ID: <20170627222609.GN3432@localhost> References: <20170626212951.GA3422@localhost> <5952980E.60707@ninebynine.org> <20170627183125.GL3432@localhost> <22241563-BA06-4125-BFE8-8D8E9114CAEF@gbiv.com> <20170627192022.GM3432@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [art] Software URNs for dependency representation X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 22:26:15 -0000 On Wed, Jun 28, 2017 at 07:32:50AM +1000, Matthew Kerwin wrote: > I think I get what you're saying, but... aren't you literally describing > HTTP URLs with DNS names in the authority? This is not at all like an https: URI. It's a different beast, even if there's a domainname in it. In the case of http: and https: the domainname *is* the location. In this case the domainname is just an input into a location resolution mechanism, one that allows local overrides. The problem with https://foo.example/somepkg-1.2.3 is that any user agent will want to go to... foo.example to fetch this. But the user agent may want to go to a mirror -- perhaps a private mirror. Now, one could edit /etc/hosts and make foo.example resolve to a local mirror... but this... sucks, no? That's just NOT OK. What I want is something like sw:/foo.example/somepkg-1.2.3, and then the UA would lookup foo.example in a local directory if there is one, else in DNS, to find one or more base URIs, then append /somepkg-1.2.3 to those base URIs, and fetch from one of them. And when I say DNS, I don't mean look for foo.example's IP addresses, but rather, look for foo.example's software repository base URIs. (What RR type to use for this is not relevant here. I don't want to get into arguments about URI vs. TXT RR types!) (Underlying all of this this is an assumption that these resources are read-only, never-changing. So anyone can setup a mirror anywhere at any time for whatever reason. Metadata might change: e.g., one might mark something as obsolete or toxic.) Nico -- From nobody Tue Jun 27 18:54:09 2017 Return-Path: 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 28C631200CF for ; Tue, 27 Jun 2017 18:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 xhjYB8-0Ad2a for ; Tue, 27 Jun 2017 18:54:05 -0700 (PDT) Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (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 86063126C22 for ; Tue, 27 Jun 2017 18:54:05 -0700 (PDT) Received: from resomta-ch2-02v.sys.comcast.net ([69.252.207.98]) by resqmta-ch2-12v.sys.comcast.net with SMTP id Q2BAd0TRr1q43Q2BAdAsk9; Wed, 28 Jun 2017 01:54:04 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-02v.sys.comcast.net with SMTP id Q2B9d3F2QnvLBQ2B9dBGhX; Wed, 28 Jun 2017 01:54:04 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v5S1s2CD011621; Tue, 27 Jun 2017 21:54:02 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v5S1s0t1011569; Tue, 27 Jun 2017 21:54:00 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Nico Williams Cc: art@ietf.org In-Reply-To: <20170626212951.GA3422@localhost> (nico@cryptonector.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 27 Jun 2017 21:54:00 -0400 Message-ID: <87a84sj2rr.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfA9IrkkB2tagICN5EkcOTPoze7/5lgMXF0933n3UogWKwx8cYSRvOGwene46DOFveDBkJzeUOTI1AiN53dfesd5jiwwjgi/DN8wt5Ipp18Q7V6xX0l9r tL45znNsO3mmPRMkZfGGMYY9S0mwuazwTRGukYKE1bzFJMTgvHXQkLvJ8RAlZKJfxF6x6Q0YAQiohg== Archived-At: Subject: Re: [art] Software URNs for dependency representation X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 01:54:07 -0000 Nico Williams writes: > But, how shall dependencies be identified? Of course, the answer is "they are identified by names". But who assigns the names, etc.? In a sense, all naming systems are the same in concept and only differ in details. A system that has already been specified is the "object identifier" system, which allows for delegation of sub-namespaces, etc. And object identifiers can already be turned into URNs. I have a soft spot in my heart for objectids. I once assigned names to RFCs: urn:oid:1.3.6.1.4.1.14490.5.1.xxxx is RFC xxxx and to releases of Sourceforge projects: urn:oid:1.3.6.1.4.1.14490.22.g.n.n is release n.n of Sourceforge group g Now you seem to be proposing as a resolution system, "Contact a well-known list of resolution servers and ask them for the information regarding the name." What's different and interesting about your problem is that in the real world, a dependency actually does live in one of a small number of servers (or their mirrors) -- at least for standard packages of common Linux software. Compare to web sites, which exist in millions of servers. But what is to be gained? Different distributions already name dependencies and they already store them in Internet-accessible servers. The only thing that's missing is having a unified naming system -- right now, a dependency is only fully identified if you know the context (the distribution) within which that dependency name is referenced. Dale From nobody Tue Jun 27 19:00:15 2017 Return-Path: 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 9B4A01200CF for ; Tue, 27 Jun 2017 19:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 S1H-pi7qTCER for ; Tue, 27 Jun 2017 19:00:10 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C80EC127775 for ; Tue, 27 Jun 2017 19:00:10 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id z62so28005487ioi.3 for ; Tue, 27 Jun 2017 19:00:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=0NtddIEOOP5TxbMHghDN1MakMUsLMb5dzNbyGCDBEYc=; b=beyXUcDv7yIJVaBjfNP8nxfxa5cz6E9Nn8W9nhiGjDhd6oWgAZ7t94U+ipubK03Kdg DlHrXaQg1Ids8YJm6goPkdINUe3WUQGrX9Z2sY9XmFL5m1pWy0YjuDjCuLKbqtcJPyJP T6GKRG2JZxtFWrxbX2I9Yjud+qYs0AEzNQCqPLS2qz0f23sVVdlFx7uPfiEUDplKNYC7 8Coiv1dsedYrIPVH34GIY3aKvmR1gQ2alY2twd1Runcc8Jps8f7xYFe2QSfgBPU5JfBg pLZRbw6biG5qeLe9KjrjAlMWk2n/f8yiW3kEediH05Vz22BVRRXsD5bwPPvQypQlidLY ibaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=0NtddIEOOP5TxbMHghDN1MakMUsLMb5dzNbyGCDBEYc=; b=dDo4xrm7bnsz/Tt0UHSUHoz4GroxH7j2TYloJuhngV6vWe0kX9+MSgsRt3KDWgbsXP grShkPRiQvcKO4QbiDYolJIkXu8YLYCLg8LQ79Dn0b9UNxeCWMQjA1E4YPWIBSTeKjHT h7VEwkqxut+a6HjnqFx/qUckBvaMPm73Z0z+MfK794Q+8x2vJopNWCa2yX+zUT37ToOX QaqwybGwFtrc8tUurxxOTtxK2661/MiGrQ34hXIDMs8RtLY3DUJqEm/AHC0Z+gMOnB2q iMXTJ2XVdDuHQjaZSVRRyz8qrK9ojWNLvQekRco0zpAG/eLlxyceGJYwotmcjEVe9pc/ fOCw== X-Gm-Message-State: AKS2vOwW+1Oz7C3KSXr2d5IRrEaZk9DCj4H6mb8jOUClNGrhKeiMTyWX zFidwb2AutjovFqVeF8dmcVsbdfVSu8q X-Received: by 10.107.24.5 with SMTP id 5mr10174186ioy.217.1498615210086; Tue, 27 Jun 2017 19:00:10 -0700 (PDT) MIME-Version: 1.0 Sender: phluid61@gmail.com Received: by 10.107.20.13 with HTTP; Tue, 27 Jun 2017 19:00:09 -0700 (PDT) Received: by 10.107.20.13 with HTTP; Tue, 27 Jun 2017 19:00:09 -0700 (PDT) In-Reply-To: <20170627222609.GN3432@localhost> References: <20170626212951.GA3422@localhost> <5952980E.60707@ninebynine.org> <20170627183125.GL3432@localhost> <22241563-BA06-4125-BFE8-8D8E9114CAEF@gbiv.com> <20170627192022.GM3432@localhost> <20170627222609.GN3432@localhost> From: Matthew Kerwin Date: Wed, 28 Jun 2017 12:00:09 +1000 X-Google-Sender-Auth: 9xBPD1O97oeOHPJwEZwQasCsoi4 Message-ID: To: Nico Williams Cc: "General Area Review Team (gen-art@ietf.org)" Content-Type: multipart/alternative; boundary="94eb2c05b69240b90f0552fb8bc9" Archived-At: Subject: Re: [art] Software URNs for dependency representation X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 02:00:14 -0000 --94eb2c05b69240b90f0552fb8bc9 Content-Type: text/plain; charset="UTF-8" On 28 Jun. 2017 08:26, "Nico Williams" wrote: On Wed, Jun 28, 2017 at 07:32:50AM +1000, Matthew Kerwin wrote: > I think I get what you're saying, but... aren't you literally describing > HTTP URLs with DNS names in the authority? This is not at all like an https: URI. It's a different beast, even if there's a domainname in it. In the case of http: and https: the domainname *is* the location. Not really, the IP address (and TCP port) is the location; the domain name (along with other URL parts) is metadata sent to that location in a query. In terms of location, the domain name is an input into a location resolution mechanism, one that allows local overrides. In this case the domainname is just an input into a location resolution mechanism, one that allows local overrides. Yeah, that. The problem with https://foo.example/somepkg-1.2.3 is that any user agent will want to go to... foo.example to fetch this. But the user agent may want to go to a mirror -- perhaps a private mirror. Now, one could edit /etc/hosts and make foo.example resolve to a local mirror... but this... sucks, no? That's just NOT OK. I'm not sure why it's not ok. Is it because things other than just your client use /etc/hosts for DNS? (And, presumably, you only want to redirect your client.) But, in general, that's what /etc/hosts is *for*. What I want is something like sw:/foo.example/somepkg-1.2.3, and then the UA would lookup foo.example in a local directory if there is one, else in DNS, to find one or more base URIs, then append /somepkg-1.2.3 to those base URIs, and fetch from one of them. And when I say DNS, I don't mean look for foo.example's IP addresses, but rather, look for foo.example's software repository base URIs. (What RR type to use for this is not relevant here. I don't want to get into arguments about URI vs. TXT RR types!) Yeah, cool, so you want a new URI (URL) scheme; you just need to define how to resolve the authority into a... service location? URI prefix? Something like that. Whether that uses DNS (A/AAAA/CNAME, SRV, TXT, whatever) or something else (e.g. a HTTP .well-known service?) depends a bit on operational/deployment considerations. I don't think there's a local override mechanism for any solution I can think of OTOH that is universal but doesn't, at some level, need /etc/hosts to override DNS for local override. Cheers -- Matthew Kerwin --94eb2c05b69240b90f0552fb8bc9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 28 Jun. 2017 08:26, "Nico Williams" <nico@cryptonector.com>= ; wrote:
On Wed, Jun 28, 2017 at= 07:32:50AM +1000, Matthew Kerwin wrote:
> I think I get what you're saying, but... aren't you literally = describing
> HTTP URLs with DNS names in the authority?

This is not at all like an https: URI.=C2=A0 It's a different bea= st, even if
there's a domainname in it.=C2=A0 In the case of http: and https: the domainname *is* the location.

Not really, the IP address (and TCP port) is= the location; the domain name (along with other URL parts) is metadata sen= t to that location in a query.

In terms of location, the domain name is an input into a location re= solution mechanism, one that allows local overrides.


=C2=A0 In this case the domainname is just an
input into a location resolution mechanism, one that allows local
overrides.

Yeah, that.



The problem with https://foo.example/somepkg-1.2.3 is that= any user
agent will want to go to... foo.example to fetch this.

But the user agent may want to go to a mirror -- perhaps a private
mirror.

Now, one could edit /etc/hosts and make foo.example resolve to a local
mirror... but this... sucks, no?=C2=A0 That's just NOT OK.

I'm= not sure why it's not ok. Is it because things other than just your cl= ient use /etc/hosts for DNS? (And, presumably, you only want to redirect yo= ur client.)

But, in gene= ral, that's what /etc/hosts is *for*.

=


What I want is something like sw:/foo.example/somepkg-1.2.3, and then
the UA would lookup foo.example in a local directory if there is one,
else in DNS, to find one or more base URIs, then append /somepkg-1.2.3
to those base URIs, and fetch from one of them.

And when I say DNS, I don't mean look for foo.example's IP addresse= s,
but rather, look for foo.example's software repository base URIs.=C2=A0= (What
RR type to use for this is not relevant here.=C2=A0 I don't want to get= into
arguments about URI vs. TXT RR types!)


Yeah, cool, so you want a new URI (URL) scheme; you just need to define ho= w to resolve the authority into a... service location? URI prefix? Somethin= g like that.

Whether that uses DNS (A/AAAA/CNAME, SRV, = TXT, whatever) or something else (e.g. a HTTP .well-known service?) depends= a bit on operational/deployment considerations.=C2=A0 I don't think th= ere's a local override mechanism for any solution I can think of OTOH t= hat is universal but doesn't, at some level, need /etc/hosts to overrid= e DNS for local override.

=
Cheers
--=C2=A0
Matthew Kerwin=C2=A0
--94eb2c05b69240b90f0552fb8bc9-- From nobody Tue Jun 27 19:06:43 2017 Return-Path: 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 9E9D01277BB for ; Tue, 27 Jun 2017 19:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=Ho6HHGu2; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=PsWpH6Wv 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 2i5QJhbI1MSj for ; Tue, 27 Jun 2017 19:06:39 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E0C812762F for ; Tue, 27 Jun 2017 19:06:39 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 7C7A5209F6; Tue, 27 Jun 2017 22:06:38 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Tue, 27 Jun 2017 22:06:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=W4F6lJacy1j8PvEWKF VJnFHk4Ykcpl5aKmrGY71vSyE=; b=Ho6HHGu2QGN6dB+MvDnAna3UsKWajCb6u/ qZIgb04CX2fm4+SghdcpBvo9CgDOjN4zRCaHbS3bqRSVO+jEMj1acB/8liqGF9Nt Rss4mZ4qrLLaoyth1kUkcDYgT8/KyyVrOj3Bq2d1px0XZZJbpFou/T7d4OcTWpon Al9Gn14kWsgJKT9q7K7nPunvFV9O/N5dTC52HYffULGiWPTPpS+2EWqeB+Sog9dI Rjt2Ys+0WW+x2PO9Vy2H5GLQT4pUzYBhd+nD+Lvha9La3NdfZMJpcLrgoe2nlAQU fUQ32m7MYff3B7iV9QqF3LZwcWr0M3hq59ga9SG4SifXtrUiLpfQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=W4F6lJacy1j8PvEWKFVJnFHk4Ykcpl5aKmrGY71vSyE=; b=PsWpH6Wv f4WXrkQ610pK/D+wQiLxQ09Ed/odhO91OhDC2Ac0FhXV0Eeqoj438Rf2OBiHpU2G XRwyWV/xdmFRc793yAxXkEYLMliEEH3qlCVdc6aQCOfFtGQ03SGCB1UlWlkxLWov EID8ui8ya0lF/Jzkx6L0hRAyr93tT62ZdybJf9mD/a5DPVPtYkkEwlZUi4sfRAs+ gvM4J6N+7aeY+xUXJjU7olWZAFeX+H4Z+BDI+70TZQt62hFwuiTaW9oXpwl5M7Wo So3CgUW9YGu86bOW0/Y/GoIkEKCcNcFtGVkcYWGiKVb0prGM0jcPpC2Hj99vt+XC MTpAR4Jl2CIE3A== X-ME-Sender: X-Sasl-enc: Hj0KcMikwnDkEFS9ibnjaUsht2P4kmhSQ5FKrGx3oeOo 1498615598 Received: from [192.168.1.18] (cpe-124-188-19-231.hdbq1.win.bigpond.net.au [124.188.19.231]) by mail.messagingengine.com (Postfix) with ESMTPA id 59B397E070; Tue, 27 Jun 2017 22:06:37 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Nottingham In-Reply-To: Date: Wed, 28 Jun 2017 12:06:34 +1000 Cc: Nico Williams , "General Area Review Team (gen-art@ietf.org)" Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170626212951.GA3422@localhost> <5952980E.60707@ninebynine.org> <20170627183125.GL3432@localhost> <22241563-BA06-4125-BFE8-8D8E9114CAEF@gbiv.com> <20170627192022.GM3432@localhost> <20170627222609.GN3432@localhost> To: Matthew Kerwin X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [art] Software URNs for dependency representation X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 02:06:42 -0000 This is not the first time this sort of thing has been suggested. I'd = put forth that the pain of modifying /etc/hosts is nothing compared to = the risk of designing and deploying such a system. For the general problem (without a solution for private repositories), = see: https://en.wikipedia.org/wiki/Metalink > On 28 Jun 2017, at 12:00 pm, Matthew Kerwin = wrote: >=20 >=20 >=20 > On 28 Jun. 2017 08:26, "Nico Williams" wrote: > On Wed, Jun 28, 2017 at 07:32:50AM +1000, Matthew Kerwin wrote: > > I think I get what you're saying, but... aren't you literally = describing > > HTTP URLs with DNS names in the authority? >=20 > This is not at all like an https: URI. It's a different beast, even = if > there's a domainname in it. In the case of http: and https: the > domainname *is* the location. >=20 > Not really, the IP address (and TCP port) is the location; the domain = name (along with other URL parts) is metadata sent to that location in a = query. >=20 > In terms of location, the domain name is an input into a location = resolution mechanism, one that allows local overrides. >=20 >=20 > In this case the domainname is just an > input into a location resolution mechanism, one that allows local > overrides. >=20 > Yeah, that. >=20 >=20 >=20 > The problem with https://foo.example/somepkg-1.2.3 is that any user > agent will want to go to... foo.example to fetch this. >=20 > But the user agent may want to go to a mirror -- perhaps a private > mirror. >=20 > Now, one could edit /etc/hosts and make foo.example resolve to a local > mirror... but this... sucks, no? That's just NOT OK. >=20 > I'm not sure why it's not ok. Is it because things other than just = your client use /etc/hosts for DNS? (And, presumably, you only want to = redirect your client.) >=20 > But, in general, that's what /etc/hosts is *for*. >=20 >=20 >=20 > What I want is something like sw:/foo.example/somepkg-1.2.3, and then > the UA would lookup foo.example in a local directory if there is one, > else in DNS, to find one or more base URIs, then append /somepkg-1.2.3 > to those base URIs, and fetch from one of them. >=20 > And when I say DNS, I don't mean look for foo.example's IP addresses, > but rather, look for foo.example's software repository base URIs. = (What > RR type to use for this is not relevant here. I don't want to get = into > arguments about URI vs. TXT RR types!) >=20 >=20 > Yeah, cool, so you want a new URI (URL) scheme; you just need to = define how to resolve the authority into a... service location? URI = prefix? Something like that. >=20 > Whether that uses DNS (A/AAAA/CNAME, SRV, TXT, whatever) or something = else (e.g. a HTTP .well-known service?) depends a bit on = operational/deployment considerations. I don't think there's a local = override mechanism for any solution I can think of OTOH that is = universal but doesn't, at some level, need /etc/hosts to override DNS = for local override. >=20 > Cheers > --=20 > Matthew Kerwin=20 > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art -- Mark Nottingham https://www.mnot.net/ From nobody Tue Jun 27 19:29:11 2017 Return-Path: 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 7216A12969E for ; Tue, 27 Jun 2017 19:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 HpE8TpXcP-MW for ; Tue, 27 Jun 2017 19:29:07 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1156E127ABE for ; Tue, 27 Jun 2017 19:29:07 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id p21so40608308qke.3 for ; Tue, 27 Jun 2017 19:29:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=UHlYbpzvW6sSYINUo/fKeb6hN5DADfJcXRVebm2aqC8=; b=e43HvAN69uS/oCJo7o7qH9zVj4bVvjVYPjQwjuPYo4U2wm5ob8ktErdjZQKBCFzKSb T4tEr89V1FVvbJj1b5yhFq0iEIJ8HM+dHYQKtltMc8CVQGG9ZMgvDp6fafhrHXI3RpUg llft42d6NM2ydaSQDCQRO/NozAmLx2tR1OrcaTKNLVKyIYTZTL95OmIqnn6vG0MWvvqm BTxDzBpNYS1HLFN4VAxL0G7u4rcZJS04EicE1fdRh+CgV2tt2ysKFMVfWhv2q4bJMQnq XPzLAM1FtTvdbTeAGs1WL9AduFAV0OflDKlhpaEjNwNX/yhNDFQsRcn+j1RCf+qar+Zj YriQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=UHlYbpzvW6sSYINUo/fKeb6hN5DADfJcXRVebm2aqC8=; b=fV9bW+h+AqQ0XhYch3SEwDof2WCMlI78/BXRafXjqLlIOvYyRWFzUUcioPHGyDxtjO omRhrkPZI30lsfMdSglCNb1mYpR6FnGSrahHY8xGRry5Ev7ZBlDHfEgKWOv/ijbqndCC qSRGl2pUoYFSgCrGablm5lGcOz9DaLWINULPYAToq7yMCOAYcKXoEpsdORnjvYx9+5ko SidoMTmAunZ2ihT5686vqhxcMai8TXL0/k3erUvwDxdZhugmw88T99IixrBmiEt2P0z+ 1+ueO3OWsQIBINxysXlMH019IJFoHzqL43kBsfU+iAvPvmPaXdHKrTOE7KBt79turQiT yF+A== X-Gm-Message-State: AKS2vOyAkWlfNDshamhMrkMIdRY2froVAK5DiRE+N9Z6drcjOy3o954q bY7ot/NFPYscIcFa7p7HihviAConbGkW X-Received: by 10.55.181.71 with SMTP id e68mr9942354qkf.91.1498616946223; Tue, 27 Jun 2017 19:29:06 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.140.102.79 with HTTP; Tue, 27 Jun 2017 19:29:05 -0700 (PDT) In-Reply-To: References: <20170626212951.GA3422@localhost> <5952980E.60707@ninebynine.org> <20170627183125.GL3432@localhost> <22241563-BA06-4125-BFE8-8D8E9114CAEF@gbiv.com> <20170627192022.GM3432@localhost> <20170627222609.GN3432@localhost> From: Phillip Hallam-Baker Date: Tue, 27 Jun 2017 22:29:05 -0400 X-Google-Sender-Auth: TEs6_C4W2lVBPmdalgLs-MnSi_M Message-ID: To: Mark Nottingham Cc: Matthew Kerwin , Nico Williams , "General Area Review Team (gen-art@ietf.org)" Content-Type: multipart/alternative; boundary="94eb2c06e968bbf0810552fbf236" Archived-At: Subject: Re: [art] Software URNs for dependency representation X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 02:29:09 -0000 --94eb2c06e968bbf0810552fbf236 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =E2=80=8B=E2=80=8BOn Tue, Jun 27, 2017 at 10:06 PM, Mark Nottingham wrote: > This is not the first time this sort of thing has been suggested. I'd put > forth that the pain of modifying /etc/hosts is nothing compared to the ri= sk > of designing and deploying such a system. https://tools.ietf.org/html/rfc6920 =E2=80=8BYou could also look at the .net architecture which uses signatures= in a similar fashion. In general you have three ways to identify something, following the trichotemy of Noth: Firstness, the identifier is the thing itself. i.e. a data uri Secondness, the identifier is formed from a property of the object. We do this in two ways: URLs are Locators, the resource is the data retrieved from http://example.com/ Fingerprints and other hashes work in reverse, they are a pseudo-unique identifier that is formed from either the data object or a key that is used to sign the data object. Thirdness, the identifier has only a purely conventional relationship to the signified. All true names have that property, their meaning arises purely from use, from an intersubjective agreement to use them as such. While this is typically implemented by reference to a registry, the registry only has authority so long as users decide to recognize it as such. It is not possible to drop Iran from the Internet by forcing ICANN to revoke its IP address block assignments. The one that I think is interesting that I have not seen applied systematically until the Mesh is the use of a fingerprint of a signature key. Yes, there is something of the sort in OpenPGP but it is an afterthought. --94eb2c06e968bbf0810552fbf236 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=E2= =80=8B=E2=80=8BOn Tue, Jun 27, 2017 at 10:06 PM, Mark Nottingham <mnot@mnot.n= et> wrote:
This is not the = first time this sort of thing has been suggested. I'd put forth that th= e pain of modifying /etc/hosts is nothing compared to the risk of designing= and deploying such a system.
=C2=A0

=E2=80=8BYou could also look at the .net architecture which uses sig= natures in a similar fashion.


In ge= neral you have three ways to identify something, following the trichotemy o= f Noth:

Firstness, the id= entifier is the thing itself. i.e. a data uri

Secondness, the identifier is formed from a property o= f the object. We do this in two ways:

URLs are Locators, the resource is the data retrieved from http://example.com/

Fingerprints and other hashes work in reverse, = they are a pseudo-unique identifier that is formed from either the data obj= ect or a key that is used to sign the data object.

Thirdness, the identifier has only a purely conve= ntional relationship to the signified. All true names have that property, t= heir meaning arises purely from use, from an intersubjective agreement to u= se them as such. While this is typically implemented by reference to a regi= stry, the registry only has authority so long as users decide to recognize = it as such. It is not possible to drop Iran from the Internet by forcing IC= ANN to revoke its IP address block assignments.


The one that I think is interesting that I have not seen appli= ed systematically until the Mesh is the use of a fingerprint of a signature= key. Yes, there is something of the sort in OpenPGP but it is an afterthou= ght.

=


--94eb2c06e968bbf0810552fbf236-- From nobody Tue Jun 27 20:13:34 2017 Return-Path: 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 EA0B5124B0A for ; Tue, 27 Jun 2017 20:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=P4arwn3V; dkim=pass (1024-bit key) header.d=yitter.info header.b=V/TG+5js 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 bGUONkXPnJCR for ; Tue, 27 Jun 2017 20:13:30 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF57D12441E for ; Tue, 27 Jun 2017 20:13:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 10225BFFDE for ; Wed, 28 Jun 2017 03:13:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1498619580; bh=iGs+xvhaqryCQIigS5e1zAtgANYQ6pV7rNclS2VzcY0=; h=Date:From:To:Subject:References:In-Reply-To:From; b=P4arwn3V8TbGDGg9foDZyutXrg0Kj/7s6P2gjE6jwb1wXANdwbYYNrFUrAAUbx35a wKCsK71/4GQ145Cy3wG2WqZ5PnbdEhhvLZ+bHIu4pMfq9H4QsKaA8MVDM/YO3MTh/+ wMUtztM4BIh6lVR7Je5hhkeWHsHz/nZOhk/4mUDQ= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qoemlyGKRShB for ; Wed, 28 Jun 2017 03:12:58 +0000 (UTC) Date: Tue, 27 Jun 2017 23:12:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1498619578; bh=iGs+xvhaqryCQIigS5e1zAtgANYQ6pV7rNclS2VzcY0=; h=Date:From:To:Subject:References:In-Reply-To:From; b=V/TG+5jsXzzmSBFm77sIhpZgOwvTJOHyAKfE4x/GF8Z2ByjnvBGj+UfoQ1ZBKVuW/ jNy+Mpj9jLsjeAv5hv6GeEeUZgcf5LwVEbeDlwbwFG9AWeBHWoZTfabC9dSGIFfSng AlPyPopTFPS2UvIfKRDsw6gzukxZSyFEgkdUJWP4= From: Andrew Sullivan To: art@ietf.org Message-ID: <20170628031258.jalhnplrbnfv4sjy@mx4.yitter.info> References: <20170626212951.GA3422@localhost> <5952980E.60707@ninebynine.org> <20170627183125.GL3432@localhost> <22241563-BA06-4125-BFE8-8D8E9114CAEF@gbiv.com> <20170627192022.GM3432@localhost> <20170627222609.GN3432@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170627222609.GN3432@localhost> Archived-At: Subject: Re: [art] Software URNs for dependency representation X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 03:13:33 -0000 Hi, I will note that the IAB has only recently solicited position papers for problems shaped almost exactly like this. https://www.iab.org/2017/06/22/call-for-participation-iab-workshop-on-explicit-internet-naming-systems/ Please note that this is not an advert: I had nothing to do with setting up that workshop, but I think it interesting (and maybe related to this thread). A On Tue, Jun 27, 2017 at 05:26:10PM -0500, Nico Williams wrote: > On Wed, Jun 28, 2017 at 07:32:50AM +1000, Matthew Kerwin wrote: > > I think I get what you're saying, but... aren't you literally describing > > HTTP URLs with DNS names in the authority? > > This is not at all like an https: URI. It's a different beast, even if > there's a domainname in it. In the case of http: and https: the > domainname *is* the location. In this case the domainname is just an > input into a location resolution mechanism, one that allows local > overrides. > > The problem with https://foo.example/somepkg-1.2.3 is that any user > agent will want to go to... foo.example to fetch this. > > But the user agent may want to go to a mirror -- perhaps a private > mirror. > > Now, one could edit /etc/hosts and make foo.example resolve to a local > mirror... but this... sucks, no? That's just NOT OK. > > What I want is something like sw:/foo.example/somepkg-1.2.3, and then > the UA would lookup foo.example in a local directory if there is one, > else in DNS, to find one or more base URIs, then append /somepkg-1.2.3 > to those base URIs, and fetch from one of them. > > And when I say DNS, I don't mean look for foo.example's IP addresses, > but rather, look for foo.example's software repository base URIs. (What > RR type to use for this is not relevant here. I don't want to get into > arguments about URI vs. TXT RR types!) > > (Underlying all of this this is an assumption that these resources are > read-only, never-changing. So anyone can setup a mirror anywhere at any > time for whatever reason. Metadata might change: e.g., one might mark > something as obsolete or toxic.) > > Nico > -- > > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Tue Jun 27 21:25:09 2017 Return-Path: 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 B5D4C1288B8 for ; Tue, 27 Jun 2017 21:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com 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 rpTOxie8bNtt for ; Tue, 27 Jun 2017 21:25:05 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8280128792 for ; Tue, 27 Jun 2017 21:25:05 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id 36217C00282C; Tue, 27 Jun 2017 21:25:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=cYO8jQ2Q0hbRu5 j++1inQcXrDPQ=; b=BdbkbkiZFtAvkj/N/nnWygMSapEiuIQFkQKnbu9rKvJ6q4 xo5vKyKs2kUh7BgFi/0WsrW9zE9WrJ27dDvApWra9neAPZ+tvk4C+YRz1FEb7Sce gt3xE+mlcV/2oYeyaaj0Xr94mIvKjZD8+y+W4EKL3d6jRXXMadtWI8/bKLJGw= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPSA id D3FF1C002828; Tue, 27 Jun 2017 21:25:04 -0700 (PDT) Date: Tue, 27 Jun 2017 23:25:02 -0500 From: Nico Williams To: Matthew Kerwin Cc: "General Area Review Team (gen-art@ietf.org)" Message-ID: <20170628042500.GO3432@localhost> References: <20170626212951.GA3422@localhost> <5952980E.60707@ninebynine.org> <20170627183125.GL3432@localhost> <22241563-BA06-4125-BFE8-8D8E9114CAEF@gbiv.com> <20170627192022.GM3432@localhost> <20170627222609.GN3432@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [art] Software URNs for dependency representation X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 04:25:07 -0000 On Wed, Jun 28, 2017 at 12:00:09PM +1000, Matthew Kerwin wrote: > On 28 Jun. 2017 08:26, "Nico Williams" wrote: > > On Wed, Jun 28, 2017 at 07:32:50AM +1000, Matthew Kerwin wrote: > > > I think I get what you're saying, but... aren't you literally describing > > > HTTP URLs with DNS names in the authority? > > > > This is not at all like an https: URI. It's a different beast, even if > > there's a domainname in it. In the case of http: and https: the > > domainname *is* the location. > > Not really, the IP address (and TCP port) is the location; the domain name > (along with other URL parts) is metadata sent to that location in a query. See below. > > In terms of location, the domain name is an input into a location > > resolution mechanism, one that allows local overrides. > > > In this case the domainname is just an > input into a location resolution mechanism, one that allows local > overrides. > > > Yeah, that. But http: and https: don't provide for that, not really. > > The problem with https://foo.example/somepkg-1.2.3 is that any user > > agent will want to go to... foo.example to fetch this. > > > > But the user agent may want to go to a mirror -- perhaps a private > > mirror. > > > > Now, one could edit /etc/hosts and make foo.example resolve to a local > > mirror... but this... sucks, no? That's just NOT OK. > > I'm not sure why it's not ok. Is it because things other than just > your client use /etc/hosts for DNS? (And, presumably, you only want to > redirect your client.) > > But, in general, that's what /etc/hosts is *for*. /etc/hosts serves that purpose, this is true, but it's not manageable, so it's not workable. > > What I want is something like sw:/foo.example/somepkg-1.2.3, and then > > the UA would lookup foo.example in a local directory if there is one, > > else in DNS, to find one or more base URIs, then append /somepkg-1.2.3 > > to those base URIs, and fetch from one of them. > > > > And when I say DNS, I don't mean look for foo.example's IP addresses, > > but rather, look for foo.example's software repository base URIs. (What > > RR type to use for this is not relevant here. I don't want to get into > > arguments about URI vs. TXT RR types!) > > Yeah, cool, so you want a new URI (URL) scheme; you just need to define how Or a better URN. > to resolve the authority into a... service location? URI prefix? Something > like that. Yes. > Whether that uses DNS (A/AAAA/CNAME, SRV, TXT, whatever) or something else > (e.g. a HTTP .well-known service?) depends a bit on operational/deployment > considerations. [...] I don't want to get into what RR types to use for this, not yet. That's a useful and important discussion, but it's too soon for it and we'd rathole. > [...]. I don't think there's a local override mechanism for any > solution I can think of OTOH that is universal but doesn't, at some level, > need /etc/hosts to override DNS for local override. No, of course, but the idea is that the specification would make a point of local overrides so that UAs that implement this get that right from day 1. Nico -- From nobody Tue Jun 27 21:29:11 2017 Return-Path: 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 903EE128792 for ; Tue, 27 Jun 2017 21:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com 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 LCBUDKb7cshz for ; Tue, 27 Jun 2017 21:29:08 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E967127867 for ; Tue, 27 Jun 2017 21:29:08 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id CCF78C00282C; Tue, 27 Jun 2017 21:29:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=3TU62hxuKyBm7Y Tzq1K4NKgcap0=; b=vOElYaa7JpVEvs75qX5T2QfAjLe7Yz82W3x7JhLyWOYSJ5 pstFMEJNlQzFTcTSn82iVCCfHYiK+Ng5FXRMyOXjjwwg7HJUn3UQDwZT153Sxg5W gi0G55khs1Q0i/GUhnR2N4Ch/Jtlil5Z9SI7uaZ1P3UKPS4pO95W0gmf3FP40= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPSA id 6DCD0C002828; Tue, 27 Jun 2017 21:29:07 -0700 (PDT) Date: Tue, 27 Jun 2017 23:29:05 -0500 From: Nico Williams To: Mark Nottingham Cc: Matthew Kerwin , "General Area Review Team (gen-art@ietf.org)" Message-ID: <20170628042904.GP3432@localhost> References: <20170626212951.GA3422@localhost> <5952980E.60707@ninebynine.org> <20170627183125.GL3432@localhost> <22241563-BA06-4125-BFE8-8D8E9114CAEF@gbiv.com> <20170627192022.GM3432@localhost> <20170627222609.GN3432@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [art] Software URNs for dependency representation X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 04:29:09 -0000 On Wed, Jun 28, 2017 at 12:06:34PM +1000, Mark Nottingham wrote: > This is not the first time this sort of thing has been suggested. I'd > put forth that the pain of modifying /etc/hosts is nothing compared to > the risk of designing and deploying such a system. The same could have been said of DNS. A lot of original DNS design decisions are suboptiomal now, and we've had a lot of pain as a result. We should have stuck with /etc/hosts forever, huh :) > For the general problem (without a solution for private repositories), see: > https://en.wikipedia.org/wiki/Metalink Yes, we can always design a solution like that. No support in UAs, just build more tools that have to be invoked separately. Screw the web? Nico -- From nobody Tue Jun 27 21:37:31 2017 Return-Path: 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 B03B61288B8 for ; Tue, 27 Jun 2017 21:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com 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 DlC_mMP6FHZx for ; Tue, 27 Jun 2017 21:37:28 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A1CD12009C for ; Tue, 27 Jun 2017 21:37:28 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id 92EF0C00282C; Tue, 27 Jun 2017 21:37:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=2K4Uy9ddVBYppd Pxwl2szx4vNaQ=; b=hVAVCckHH8CS8IW691WESghgpe+BiIflzh8nEfpvXsQRcR /drb5Cuoxvuh7TepsIqalxImcDZwCuF7IIj/nIs713GEw+/3BNtAMRJWC9M2S0nd vae/aEhVbdy5JeShpCOeDhnGT3PKIzhZYr3VQsNx16ywnqcKIulpSyqe6v1k0= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPSA id 2B1F2C002828; Tue, 27 Jun 2017 21:37:27 -0700 (PDT) Date: Tue, 27 Jun 2017 23:37:24 -0500 From: Nico Williams To: Phillip Hallam-Baker Cc: Mark Nottingham , Matthew Kerwin , "General Area Review Team (gen-art@ietf.org)" Message-ID: <20170628043723.GQ3432@localhost> References: <20170626212951.GA3422@localhost> <5952980E.60707@ninebynine.org> <20170627183125.GL3432@localhost> <22241563-BA06-4125-BFE8-8D8E9114CAEF@gbiv.com> <20170627192022.GM3432@localhost> <20170627222609.GN3432@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [art] Software URNs for dependency representation X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 04:37:30 -0000 On Tue, Jun 27, 2017 at 10:29:05PM -0400, Phillip Hallam-Baker wrote: > On Tue, Jun 27, 2017 at 10:06 PM, Mark Nottingham wrote: > > This is not the first time this sort of thing has been suggested. I'd put > > forth that the pain of modifying /etc/hosts is nothing compared to the risk > > of designing and deploying such a system. > > https://tools.ietf.org/html/rfc6920 > > You could also look at the .net architecture which uses signatures in a > similar fashion. I'm not at all against hashes. But names are useful things! Otherwise we'd never ever have had the DNS, or URNs, or anything with names, and we'd be writing everything in assembly. Let's set aside -for one paragraph- whether I want a URI or something else that is name-like. Hashes surely fit somewhere in the architecture, but *names* are necessary for humans to deal with. So whatever the *name* thingy is (URI, something else), it needs resolution. Now come back to whether this wants to be a URI or not. Are URIs (URNs in particular) names that can be shown to users? Or are they to be hidden from users? My answer: URIs have leaked into user interfaces. They are very commonplace. While some non-name-like URI forms are certainly useful and used and to be used, we still need some URI forms that are name-like and that users can handle. URIs have some very useful behaviors, not the least of which is that UAs are an interface to many URI schemes, and usually are pluggable or extensible to handle new URI schemes. Nico -- From nobody Tue Jun 27 21:42:39 2017 Return-Path: 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 A172B126B72 for ; Tue, 27 Jun 2017 21:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 40o8Ha8-OaBR for ; Tue, 27 Jun 2017 21:42:34 -0700 (PDT) Received: from fallback2.mail.ox.ac.uk (fallback2.mail.ox.ac.uk [129.67.1.167]) by ietfa.amsl.com (Postfix) with ESMTP id D252B12009C for ; Tue, 27 Jun 2017 21:42:33 -0700 (PDT) Received: from relay12.mail.ox.ac.uk ([129.67.1.163]) by fallback2.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1dPuTk-0000yl-8C for art@ietf.org; Tue, 27 Jun 2017 18:40:44 +0100 Received: from smtp5.mail.ox.ac.uk ([163.1.2.207]) by relay12.mail.ox.ac.uk with esmtp (Exim 4.89) (envelope-from ) id 1dPuSB-0007V6-dh; Tue, 27 Jun 2017 18:39:11 +0100 Received: from gklyne38.plus.com ([81.174.129.24] helo=conina-wl.atuin.ninebynine.org) by smtp5.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1dPuSA-0004KR-J5; Tue, 27 Jun 2017 18:39:07 +0100 Message-ID: <5952980E.60707@ninebynine.org> Date: Tue, 27 Jun 2017 18:38:22 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Nico Williams , art@ietf.org References: <20170626212951.GA3422@localhost> In-Reply-To: <20170626212951.GA3422@localhost> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 X-Oxmail-Spam-Status: score=0.0 tests=none X-Oxmail-Spam-Level: / Archived-At: Subject: Re: [art] Software URNs for dependency representation X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 04:42:37 -0000 On 26/06/2017 22:29, Nico Williams wrote: > > The following is so obvious (I think!) that I suspect it's been done, or > at least discussed. If so, I would appreciate pointers and I apologize > for the noise. > > > Suppose you have a build system that lets a recipe refer to > dependencies. Well that's very common place, naturally. > > But, how shall dependencies be identified? > > In the big wide open Internet the answer is likely to be: URLs. Strictly, I'd say *on the Web* the answer is URLs (aka URIs). The Internet could and does use all sorts of identifiers. > > But URLs come with a problem: you might need to change locations (e.g., > mirrors). Then you have to edit all your recipes. Worse, you have to > edit all the upstream recipes! Well, it depends on the kind of URI that you use. There are some that are location-independent (e.g. uuid:, ni:). URNs are URIs too! Or even with HTTP URIs, they may be primarile identifiers (e.g. DOIs via http://dx.doi.org, or PURLs via purl.org). In the Web community, it's a well-used pattern to use purl.org (aka PURLs) for identifiers where the primary domain may be insufficiently stable. (There's also another initiative, w3id, or something like that). These solutions all depend on introducing a level of indirection (so probably sub-optimal for active protocol, use), and one still depends to some extent on the redirecting intermediary. URNs might be a good solution for what you propose. But an advantage of using http URIs for identifiers is that it is possible (in principle) to dereference them to learn more about the thing identified (the "follow your nose" principle). Finally, Zenodo (under auspices of CERN IIRC) operate a GitHub-integrated redirection service for DOIs (and hence http://doi.org URIs) that can be registered for software. E.g. http://doi.org/10.5281/zenodo.582881 is an identifier for a version of some software I'm working on. Maybe DOIs are an answer you could use? You provide a list of details to be "encoded" in a URI. Identifiers don't really work that way: they name, not encode. The point here is that if you have to know a bunch of details and an assembly rule to construct a URI, it's not really working as a URI, more like a URI-like syntax for encoding stuff. I suspect that what you really need is to be able to generate different identifiers for any variation of the various variables you mention. Finally, I'll note that there was some work a while ago for URN (and arbitrary URI) resolution, going by the name of DDDS: see https://tools.ietf.org/html/rfc3401 and friends. #g -- > > E.g., you depend on a library that depends on gcc, with that dependency > given as a URL to a location you cannot reach (e.g., in an intranet). > > We need something better than URLs, something like... URNs! > > urn:software:foo-1.2.3rc1/git/a1b2c3d4... > urn:software:foo-1.2.3rc1/git/tag/1_2_3rc1 > urn:software:foo-1.2.3rc1/git/tag/1_2_3rc1?default_location= > > or > > urn:brew:foo-1.2.3rc1/git/tag/1_2_3rc1 > urn:debian:stretch/foo-1.2.3 > urn:SomeGitServiceProvider:foo-1.2.3rc1/tag/1_2_3rc1 > > What needs to be encoded? Here's a few things: > > - source (not location) > > This would be the NID of the URN. > > In the above it's "software", and that's probably not right as you'll > see. > > Vendors/distros/whatever could each have their own, as each may have > different location resolution methods. Alternatively we could have a > sub-namespace encoded in the NSS of the URN. > > Having as few namespaces as possible would be nice, but since a name > resolution service will be needed, it's reasonable to expect at least > a few namespaces. > > Perhaps Debian might like a namespace per-release. Or perhaps the > release would be in the NSS part of the URN as in the above example. > > Everything else definitely goes in the NSS part of the URN. > > - name of software, naturally > > - software version information > > This might include things like git commit hashes, tag names, ... > > - perhaps a way to distinguish built "package" from "source" (maybe > this should be implied by the namespace) > > - OPTIONAL: perhaps a query or fragment by which to identify one or > more locations for the software > > This is for things that don't fit into namespaces for any packaging > or VCS services. > > - OPTIONAL: hash of software (e.g., when other versioning information > does not provide enough secure version identification information) > > - OPTIONAL: signature(s) > > Signatures could instead be found in the same way as the software, > and would be bound by any hash that appears in the URN. > > > Finding locations for software in a relatively small number of > namespaces is easy: make it configurable in the software that needs it > and provide a default configuration with default locations. These could > be listed in an IANA registry, naturally. > > Location resolution of these sorts of URNs is easy then: first determine > if the namespace is supported by the software consuming the URN, and if > so then resolve a root location(s) (see above), lastly employ whatever > additional resolution the namespace owner specifies. > > URN namespace registration information could be used to make this > location resolution automatically available in all/most cases. > > > Thoughts? > > Nico >