[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
>