[Uri-review] Response to 'leaprofrogans' scheme proposal (was: Wi-Fi Alliance permanent scheme registration -review request)
Graham Klyne <gk@ninebynine.org> Sat, 06 October 2018 11:13 UTC
Return-Path: <gk@ninebynine.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 0E4EA130DE9 for <uri-review@ietfa.amsl.com>; Sat, 6 Oct 2018 04:13:54 -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 1V8CGMQOH_On for <uri-review@ietfa.amsl.com>; Sat, 6 Oct 2018 04:13:51 -0700 (PDT)
Received: from relay14.mail.ox.ac.uk (relay14.mail.ox.ac.uk [163.1.2.162]) (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 D4138130DDD for <uri-review@ietf.org>; Sat, 6 Oct 2018 04:13:50 -0700 (PDT)
Received: from smtp6.mail.ox.ac.uk ([163.1.2.206]) by relay14.mail.ox.ac.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <gk@ninebynine.org>) id 1g8kWq-0002HO-jj; Sat, 06 Oct 2018 12:13:48 +0100
Received: from gklyne38.plus.com ([81.174.129.24] helo=conina.atuin.ninebynine.org) by smtp6.mail.ox.ac.uk with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <gk@ninebynine.org>) id 1g8kWp-0003Af-LT; Sat, 06 Oct 2018 12:13:47 +0100
Message-ID: <5BB898EA.8020607@ninebynine.org>
Date: Sat, 06 Oct 2018 12:13:46 +0100
From: Graham Klyne <gk@ninebynine.org>
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: Larry Masinter <LMM@acm.org>, Gaurav Jain <gjain@wi-fi.org>, Ted Hardie <ted.ietf@gmail.com>
CC: "uri-review@ietf.org" <uri-review@ietf.org>
References: <MW2PR07MB4025146F1176A4C37EA6B908F91E0@MW2PR07MB4025.namprd07.prod.outlook.com> <CA+9kkMAuwgYDPqt=GKbNf9FpoiCWw6=N01j0wKxxnYAkiGZWYQ@mail.gmail.com> <DM5PR07MB40226A1E81B5A1B2221F85A9F9EB0@DM5PR07MB4022.namprd07.prod.outlook.com> <5bb81e3a.1c69fb81.2691e.f41f@mx.google.com> <5BB88251.8010402@ninebynine.org>
In-Reply-To: <5BB88251.8010402@ninebynine.org>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Oxford-Username: zool0635
X-Oxmail-Spam-Status: score=0.0 tests=none
X-Oxmail-Spam-Level: /
Archived-At: <https://mailarchive.ietf.org/arch/msg/uri-review/zCVlD-xXUBtIbioZr0tm0qMDsVw>
Subject: [Uri-review] Response to 'leaprofrogans' scheme proposal (was: Wi-Fi Alliance permanent scheme registration -review request)
X-BeenThere: uri-review@ietf.org
X-Mailman-Version: 2.1.29
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: Sat, 06 Oct 2018 11:13:54 -0000
Hi all, Alexey just pointed out I confused two different proposals. My previous message is actually a response to https://mailarchive.ietf.org/arch/msg/uri-review/1NP3Q5xB6JZt6nNxFLa3g7MAnGs, though triggered by Larry's comment about encoding. Sorry for the noise. (Though maybe there's a pattern hiding in the confusion?) #g -- On 06/10/2018 10:37, Graham Klyne wrote: > Hi, > > Larry's comment raised a flag for me, so I took a look at the referenced I-D [1] > (per https://mailarchive.ietf.org/arch/msg/uri-review/1NP3Q5xB6JZt6nNxFLa3g7MAnGs). > > [1] > https://datatracker.ietf.org/doc/draft-op3ft-leaptofrogans-uri-scheme/?include_text=1 > > > A touchstone I have in situations like this is to ask the question "what do > instances of this URI scheme identify?", and in this case I think it's clear > enough that they identify a "frogans site" (whatever that may be). So far, so > good. > > > However, reading the draft, I have other concerns: > > > 1. Section 1: it's not at all clear what FrogAns can achieve that is not > achievable using WWW and appropriate media types. (Which somewhat supports > Larry's point.) There is plenty of "visual rather than text-based > communication" that can be and is implemented using WWW. I don't see this as a > blocker, but it maybe suggests the documentation could be more helpful. > > > 2. Section 2, according to the registration template, is the goto reference for > scheme semantics. But looking at this, I'm not seeing much description of > semantics. > > I don't know what the first paragraph of section 2 is actually intended to mean. > I can't recognize the characterization of URI usage offered here. > > The second paragraph talks about referencing the Web from frogans sites, which > doesn't seem to need a new URI scheme. > > The third paragraph talks about referencing frogans sites from the Web, which I > assume is the intended use of this scheme. The goals suggested here appear to > assume very broad deployment of the frogans scheme implementation, which is not > something I think is likely to happen (especially since the technology, or at > least its name, appears to be quite proprietary). For ease of deployment (at > scale), I think Larry's point about using a MIME type is particularly relevant. > Also, RFC7595 points out the potential high cost of deploying new URI schemes > [2]. > > [2] https://tools.ietf.org/html/rfc7595#section-3.1 > > (I personally think that schemes like "mailto:" set a poor precedent for URI > scheme use, as they obscure the role of URIs as identifiers and locators of > resources in the Web. But that horse being long bolted doesn't mean we can't > try to do better.) > > > frogans is described as having a "slide description language" format (FSDL).. > (FSDL even appears to include a format for sending requests to servers.) Is > there any reason that FSDL cannot be accessed over the web using HTTP, and > interpreted/dispatched to a frogans player? This doesn't mean that HTTP has be > be used by frogans native applications, but IMO would allow frogans to integrate > more easily into non-frogans environments by exploiting existing protocols. > E.g., it could allow things like sending FSDL in email and having the recipient > client dispatch to a frogans player. > > It may well be that there is a good case for having a new URI scheme for > frogans, but I feel the draft doesn't really explain it. Understanding why > HTTP+media type doesn't work just as well for the intended use would help me to > understand what that case could be. > > #g > -- > > > On 06/10/2018 03:30, Larry Masinter wrote: >> I think they might want to reconsider whether they need a URI scheme at all, >> rather than a MIME type. >> When you have a complex but extensible data structure, it’s more resilient. >> And if you have >> Situations where you really need to serialize as a URI, you can always do it >> with a data: URI. >> >> Larry >> -- >> http://LarryMasinter.net >> >> From: Gaurav Jain >> Sent: Friday, October 5, 2018 3:24 PM >> To: Ted Hardie >> Cc: uri-review@ietf.org >> Subject: Re: [Uri-review] Wi-Fi Alliance permanent scheme registration -review >> request >> >> Thank you Ted for your helpful suggestions. Wi-Fi Alliance discussed this >> feedback and think the second of your suggestions on how to have an extensible >> Bootstrapping Information URI is preferable. We would therefore like to >> additionally have a separate registry of tokens, initially populated by C, M, >> I, and K with definitions taken from the description we have provided. As a >> condition of adding to that registry may we suggest 'Expert Review' as a >> registration procedure for new tokens with myself, Gaurav Jain >> <gjain@wi-fi.org> as the designated expert. Alternate registration procedures >> are possible if 'Expert Review' is not appropriate in your estimation. >> >> Thanks and regards, >> >> Gaurav Jain >> Senior Manager, Program Technology >> +1-408-400-7158 Office >> +1-408-674-1441 Mobile >> >> Wi-Fi Alliance >> www.wi-fi.org >> http://twitter.com/wifialliance >> www.facebook.com/wificertified >> >> Visit our blog, The Beacon, for Wi-Fi industry topics and trends >> >> From: Ted Hardie <ted.ietf@gmail.com> >> Sent: Tuesday, September 18, 2018 7:45 AM >> To: Gaurav Jain <gjain@wi-fi.org> >> Cc: uri-review@ietf.org >> Subject: Re: [Uri-review] Wi-Fi Alliance permanent scheme registration - >> review request >> >> Hi Guarav, >> >> Thanks for your message. Poking at the spec, the syntax of the dpp scheme >> appears to be given as: >> " >> dpp-qr = “DPP:” [channel-list “;”] [mac “;”] [information “;”] public-key “;;” >> pkex-bootstrap-info = [information] >> channel-list = “C:” class-and-channels *(“,” class-and-channels) >> class-and-channels = class “/” channel *(“,” channel) >> class = 1*3DIGIT >> channel = 1*3DIGIT >> mac = “M:” 6hex-octet ; MAC address >> hex-octet = 2HEXDIG >> information = “I:” *(%x20-3A / %x3C-7E) ; semicolon not allowed >> public-key = “K:” *PKCHAR ; DER of ASN.1 SubjectPublicKeyInfo encoded in >> “base64” as per [14] >> PKCHAR = ALPHA / DIGIT / %x2b / %x2f / %x3d >> >> The channel-list ABNF rule allows a list of IEEE 802.11 global operating class >> and channel (Annex E of [2]) value pairs to >> be specified. The MAC ABNF rule expresses the MAC address as a string of six >> hex-octets. The information ABNF rule >> allows freeform information to accompany the public key. >> The bootstrapping information may be extended in future updates of the >> technical specification. Devices parsing this >> information should ignore unknown semicolon separated components in the dpp-qr >> and pkex-bootstrap-info instantiations >> to be forward compatible with such extensions." >> >> The last paragraph indicates that this is subject to later extension, but the >> syntax does not appear to be versioned and there does not appear to be any >> requirement for the placement of future extensions. My experience is that >> this could well result in later interoperability problems. >> >> There seem to be a couple of ways to make that work, if you do not anticipate >> registering dpp2 and so on. One would be to include later extensions within >> the current free-form Information field, declaring a new delimiter,which would >> be understood by the later version. Reserving the delimiter now would be >> useful, if that is your choice. Another would be to generalize this slightly >> so that the syntax of the scheme is simply (scheme name) ":" followed by a >> series of token:*PKCHAR pairs. You can then have a separately updated >> registry of the tokens, which would have C, M, I, K, present and which would >> be matched in your spec to the limitations. As you introduce new tokens, you >> can update the registry. If you go that path, I would suggest splitting class >> and channel so that they are independent tokens, but this is a stylistic >> suggestion only. >> >> My personal views only, >> >> regards, >> >> Ted Hardie >> >> On Mon, Sep 17, 2018 at 1:14 PM, Gaurav Jain <gjain@wi-fi.org> wrote: >> Dear IETF URI review committee, >> >> Wi-Fi Alliance would like to submit a scheme registration request for your >> review and consideration. Attached with this email you should find the following: >> 1. Scheme registration request standalone document >> 2. Latest published Wi-Fi Alliance technical specification for Device >> Provisioning Protocol >> (https://www.wi-fi.org/file/device-provisioning-protocol-specification-v10) >> covering the details of the protocol, URI definition, syntax, URI format and >> associated information >> >> Since the registration request is for a ‘permanent’ registration, Wi-Fi >> Alliance has reviewed the requirements listed in section 3 (Requirements for >> Permanent Scheme Definitions) of RFC 7595 and have found that this >> registration request satisfies the listed requirements. As a next step, we >> request you to review this scheme registration request and provide your >> comments to us by Oct-15 2018. >> >> Thanks and regards, >> >> Gaurav Jain >> Senior Manager, Program Technology >> +1-408-400-7158 Office >> +1-408-674-1441 Mobile >> >> Wi-Fi Alliance >> www.wi-fi.org >> http://twitter.com/wifialliance >> www.facebook.com/wificertified >> >> Visit our blog, The Beacon, for Wi-Fi industry topics and trends >> >> >> _______________________________________________ >> Uri-review mailing list >> Uri-review@ietf.org >> https://www.ietf.org/mailman/listinfo/uri-review >> >> >> >> >> >> _______________________________________________ >> Uri-review mailing list >> Uri-review@ietf.org >> https://www.ietf.org/mailman/listinfo/uri-review >> > > _______________________________________________ > Uri-review mailing list > Uri-review@ietf.org > https://www.ietf.org/mailman/listinfo/uri-review >
- [Uri-review] Wi-Fi Alliance permanent scheme regi… Gaurav Jain
- Re: [Uri-review] Wi-Fi Alliance permanent scheme … Ted Hardie
- Re: [Uri-review] Wi-Fi Alliance permanent scheme … Gaurav Jain
- Re: [Uri-review] Wi-Fi Alliance permanent scheme … Gaurav Jain
- Re: [Uri-review] Wi-Fi Alliance permanent scheme … Ted Hardie
- Re: [Uri-review] Wi-Fi Alliance permanent scheme … Larry Masinter
- Re: [Uri-review] Wi-Fi Alliance permanent scheme … Graham Klyne
- [Uri-review] Response to 'leaprofrogans' scheme p… Graham Klyne
- Re: [Uri-review] Wi-Fi Alliance permanent scheme … Gaurav Jain
- Re: [Uri-review] Wi-Fi Alliance permanent scheme … Gaurav Jain
- Re: [Uri-review] Response to 'leaprofrogans' sche… Benjamin PHISTER