[Uri-review] Response to 'leaprofrogans' scheme proposal (was: Wi-Fi Alliance permanent scheme registration -review request)

[Graham Klyne <[e-mail]>]

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: [e-mail]
>> 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
>> <[e-mail]> 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
>> [phone] Office
>> [phone] 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 <[e-mail]>
>> Sent: Tuesday, September 18, 2018 7:45 AM
>> To: Gaurav Jain <[e-mail]>
>> Cc: [e-mail]
>> 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 <[e-mail]> 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
>> [phone] Office
>> [phone] 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/uri-review
>>
>>
>>
>>
>>
>> _______________________________________________
>> Uri-review mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/uri-review
>>
>
> _______________________________________________
> Uri-review mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uri-review
>