Subject: Re: [Uri-review] Wi-Fi Alliance permanent scheme registration - review request

From: Gaurav Jain <[email-masked]>
Date: Fri, 5 Oct 2018 22:23:07 +0000

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 <[email-masked]<mailto:[email-masked]>> 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://www.wi-fi.org/>
http://twitter.com/wifialliance
www.facebook.com/wificertified<http://www.facebook.com/wificertified>

Visit our blog, The Beacon<http://www.wi-fi.org/beacon>, for Wi-Fi industry topics and trends

From: Ted Hardie <[email-masked]>
Sent: Tuesday, September 18, 2018 7:45 AM
To: Gaurav Jain <[email-masked]>
Cc: [email-masked]
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 <[email-masked]<mailto:[email-masked]>> 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://www.wi-fi.org/>
http://twitter.com/wifialliance
www.facebook.com/wificertified<http://www.facebook.com/wificertified>

Visit our blog, The Beacon<http://www.wi-fi.org/beacon>, for Wi-Fi industry topics and trends

_______________________________________________
Uri-review mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/uri-review

---

From: Ted Hardie <[email-masked]>
Date: Fri, 5 Oct 2018 15:36:00 -0700

Hi Gaurav,

Thanks for considering my suggestions.  I personally see no problem with
Expert Review as the registration requirement here.  It is somewhat common
in those cases to include instructions to the expert (e.g. "Expert should
confirm that the registered item is described in a specification recognized
by the Wi-Fi Alliance"); you might consider that in this case if the expert
might change to another individual at a later time.

regards,

Ted Hardie

On Fri, Oct 5, 2018 at 3:23 PM Gaurav Jain <[email-masked]> wrote:

> 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 <[email-masked]> as the designated expert. Alternate
> registration procedures are possible if 'Expert Review' is not appropriate
> in your estimation.
>
>
>
> Thanks and regards,
>
>
>
> Gaurav Jain
> www.wi-fi.org
> www.facebook.com/wificertified
>
>
>
> Visit our blog, The Beacon <http://www.wi-fi.org/beacon>, for Wi-Fi
> industry topics and trends
>
>
>
> *From:* Ted Hardie <[email-masked]>
> *Sent:* Tuesday, September 18, 2018 7:45 AM
> *To:* Gaurav Jain <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [Uri-review] Wi-Fi Alliance permanent scheme registration
> - review request
>
>
>
> Hi Guarav,
>
>
>
> 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
> 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
> 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 <[email-masked]> wrote:
>
> 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:
>
>    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
> www.wi-fi.org
> www.facebook.com/wificertified
>
>
>
> Visit our blog, The Beacon <http://www.wi-fi.org/beacon>, for Wi-Fi
> industry topics and trends
>
>
>
>
> [email-masked]

---

From: Larry Masinter <[email-masked]>
Date: Fri, 5 Oct 2018 19:30:19 -0700

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: [email-masked]
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 <[email-masked]> as the designated expert. Alternate registration procedures are possible if 'Expert Review' is not appropriate in your estimation.

Thanks and regards,

Gaurav Jain
 
Wi-Fi Alliance
www.wi-fi.org

Visit our blog, The Beacon, for Wi-Fi industry topics and trends

Hi Guarav,

My personal views only,

regards,

Ted Hardie

 
 
Thanks and regards,
 
Gaurav Jain
 
Wi-Fi Alliance
www.wi-fi.org
 
Visit our blog, The Beacon, for Wi-Fi industry topics and trends

---

From: Graham Klyne <[email-masked]>
Date: Sat, 06 Oct 2018 10:37:21 +0100

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

---

From: Graham Klyne <[email-masked]>
Date: Sat, 06 Oct 2018 12:13:46 +0100

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:
> frogans is described as having a "slide description language" format (FSDL)..
>> 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
>> <[email-masked]> as the designated expert. Alternate registration procedures
>> are possible if 'Expert Review' is not appropriate in your estimation.
>>
>> Thanks and regards,
>>
>> Gaurav Jain
>> The channel-list ABNF rule allows a list of IEEE 802.11 global operating class
>> and channel (Annex E of [2]) value pairs to
>> 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
>>
>> review and consideration. Attached with this email you should find the following:
>> 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
>>
>> Alliance has reviewed the requirements listed in section 3 (Requirements for
>> Permanent Scheme Definitions) of RFC 7595 and have found that this

---

From: Gaurav Jain <[email-masked]>
Date: Tue, 9 Oct 2018 22:33:17 +0000

Thank you Ted for the suggestion. We will follow your advice of including instructions to the expert in the submission.

Thanks and regards,

Gaurav Jain

Wi-Fi Alliance

From: Ted Hardie <[email-masked]>
Sent: Friday, October 05, 2018 3:36 PM
To: Gaurav Jain <[email-masked]>
Cc: [email-masked]
Subject: Re: [Uri-review] Wi-Fi Alliance permanent scheme registration - review request

Hi Gaurav,

Thanks for considering my suggestions.  I personally see no problem with Expert Review as the registration requirement here.  It is somewhat common in those cases to include instructions to the expert (e.g. "Expert should confirm that the registered item is described in a specification recognized by the Wi-Fi Alliance"); you might consider that in this case if the expert might change to another individual at a later time.

regards,

Ted Hardie

On Fri, Oct 5, 2018 at 3:23 PM Gaurav Jain <[email-masked]<mailto:[email-masked]>> wrote:
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 <[email-masked]<mailto:[email-masked]>> as the designated expert. Alternate registration procedures are possible if 'Expert Review' is not appropriate in your estimation.

Thanks and regards,

Gaurav Jain

Wi-Fi Alliance

From: Ted Hardie <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, September 18, 2018 7:45 AM
To: Gaurav Jain <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Uri-review] Wi-Fi Alliance permanent scheme registration - review request

Hi Guarav,

My personal views only,

regards,

Ted Hardie

Thanks and regards,

Gaurav Jain

Wi-Fi Alliance

---

From: Gaurav Jain <[email-masked]>
Date: Tue, 9 Oct 2018 22:34:42 +0000

Thank you Larry for your suggestion.
After discussion within Wi-Fi Alliance, we have concluded that the use of URI serves Device Provisioning Protocol specification and implementations and since the DPP specification is already published, we would like to pursue the original request submitted.

Thanks and regards,

Gaurav Jain

Wi-Fi Alliance

From: Larry Masinter <[email-masked]> On Behalf Of Larry Masinter
Sent: Friday, October 05, 2018 7:30 PM
To: Gaurav Jain <[email-masked]>; Ted Hardie <[email-masked]>
Cc: [email-masked]
Subject: RE: [Uri-review] Wi-Fi Alliance permanent scheme registration -review request

Larry
--
http://LarryMasinter.net

From: Gaurav Jain<mailto:[email-masked]>
Sent: Friday, October 5, 2018 3:24 PM
To: Ted Hardie<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Uri-review] Wi-Fi Alliance permanent scheme registration -review request

Thanks and regards,

Gaurav Jain

Wi-Fi Alliance

Hi Guarav,

My personal views only,

regards,

Ted Hardie

Thanks and regards,

Gaurav Jain

Wi-Fi Alliance

---

From: Benjamin PHISTER <[email-masked]>
Date: Sun, 28 Oct 2018 13:07:19 +0100

Hi Graham,

Sorry for the late answer. I had some problems posting on the
mailing list -- a spam filter got in the way.

Please find below (inline) our feedback on your comments and
suggestions.

Thanks again,

Ben Phister

From: Benjamin PHISTER
<[email-masked]>

Subject:
[Uri-review] Response to 'leaprofrogans' scheme proposal

Date:
Sunday, Oct 7, 2018 1:15 PM CEST

To: Graham
Klyne <[email-masked]>

Cc:
[email-masked] <[email-masked]>

Hi Graham.

Thanks for your comments and suggestions. We will respond soon.

Regards,

Ben Phister

From: Graham Klyne <[email-masked]>

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

Date:
Saturday, Oct 6, 2018 1:13 PM CEST

To:
Larry Masinter <[email-masked]>,
Gaurav Jain <[email-masked]>,
Ted Hardie <[email-masked]>

Cc: [email-masked]
<[email-masked]>

Hi all,

Sorry for the noise.

#g
--

> blocker, but it maybe suggests the documentation could be more helpful.

To keep the draft focused on the 'leaptofrogans' URI scheme, we
didn't want to include a detailed discussion of the similarities and
differences between Frogans sites and Web sites. However, we
included in the draft a reference to Section 1.4 "Frogans sites and
Web sites" of the technical specification of the Frogans Slide
Description Language [FSDL] because such a discussion is available
there.

> least its name, appears to be quite proprietary). For ease of deployment(at

Actually, we already explored the use of a MIME type as a means to
include on a Web page a link enabling end users to launch Frogans
Player on a given Frogans site. In 2006, the 'vnd.frogans.ltf' media
type was registered with IANA
(https://www.iana.org/assignments/media-types/application/vnd.frogans.ltf),
implemented in Frogans Player, and tested. But finally, the use of a
media type was rejected by the OP3FT for the following main reasons:

- For any such link included on a Web page, the author had to create
and host a .ltf file on the Web server hosting that Web page, which
was cumbersome. Furthermore, prior to creating such links, the
author had to ask the server administrator to associate the .ltf
files with the 'vnd.frogans.ltf' media type on the server.

- Alternatively, the author could create a link via a redirection
service (leaptofrogans.net). That service generated a .ltf file on
the fly while associating it with the 'vnd.frogans.ltf' media type.
But that alternative raised privacy concerns, and potentially added
latency for end users.

- On the Web browser side, especially on mobile devices which have
become the principal means for end users to access the Internet, it
appeared that using a media type from a Web page to launch another
application did not work well across device operating systems.

> client dispatch to a frogans player.

Since version 3.0 of the Frogans Slide Description Language (FSDL),
as stated in Section 1.2 "Purpose" of its technical specification,
FSDL works on top of Uniform Content Server Request (UCSR), a new
framework designed and developed by the OP3FT to make the Frogans
technology independent from data-transport protocols.

The UCSR framework provides a client application with an abstraction
layer for uniformly requesting and receiving data from a content
server, while ensuring a predetermined security level.

Note that UCSR does not propose new networking protocols. It
utilizes existing protocols widely used on the
Internet such as IP, DNS, TCP, TLS, and HTTP.

For more information on UCSR (and also to get an overall
understanding of the Frogans technology), see Frogans Technology
Overview on the official Web site of the Frogans technology
(https://www.frogans.org/en/resources/overview/access.html).

> HTTP+media type doesn't work just as well for the intended use would helpme to
>> When you have a complex but extensible data structure, it’s more resilient.

The 'leaptofrogans' URI scheme doesn't have a complex or extensible
data structure. It just contains a Frogans address (e.g.
frogans*HelloWorld) which identifies a Frogans site.

>> And if you have
>> The channel-list ABNF rule allows a list of IEEE 802.11 global operatingclass
>> be specified. The MAC ABNF rule expresses the MAC address as a string ofsix
>> hex-octets. The information ABNF rule
>> the current free-form Information field, declaring a new delimiter,whichwould
>> so that the syntax of the scheme is simply (scheme name) ":" followed bya
>> can update the registry. If you go that path, I would suggest splittingclass
>> covering the details of the protocol, URI definition, syntax, URI formatand
>> associated information
>>
>> Alliance has reviewed the requirements listed in section 3 (Requirementsfor

--
Benjamin Phister
Head of Technical Specifications
[email-masked]

OP3FT
6 square Mozart
75016 Paris - France
Tel: +33 1 5392 0040
https://www.op3ft.org/
frogans*op3ft

--
Benjamin Phister
Head of Technical Specifications
[email-masked]

OP3FT
6 square Mozart
75016 Paris - France
Tel: +33 1 5392 0040
https://www.op3ft.org/
frogans*op3ft