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

Ted Hardie <> Tue, 18 September 2018 14:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 67A50130E44 for <>; Tue, 18 Sep 2018 07:45:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8TUVgPSJ4Aac for <>; Tue, 18 Sep 2018 07:45:55 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D7B8A130E04 for <>; Tue, 18 Sep 2018 07:45:54 -0700 (PDT)
Received: by with SMTP id 13-v6so2036559ois.1 for <>; Tue, 18 Sep 2018 07:45:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rN5d09uS3f79SOYQXRnTh+xW2A6MAER1iSXnOjOPztQ=; b=lUxVebwBGCFuSsuIw055NvIZnW0Qd1LuOFOYRS93swkJaoGO8NjA531Br1/HTyCSXK 0U7hIAzMqJnQ+qNXRuAG14csDoqHYPT4YvYJbYwq7XjtsJZO3k43NhqT9Mrb8gTnx/py kS0Mv3ASpcG6ApOAkcLKh61MBM40ggo/WDW4fpREnRB0xEYC2PwV0BfEEOW3Z3CtVwTH bViCgas02en3bUnAuMYAjzlvP/m6TeziES5p8n8CBYzN+ACKE5pBPJZupFRJ5pYIyZdT Dl3gV0F7akPCZ5qKupFy+jOhNt2FScwQfPg93CXwFTiXrKqsIlh9PJtVcFyyJALeI+dM rNGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rN5d09uS3f79SOYQXRnTh+xW2A6MAER1iSXnOjOPztQ=; b=mMKLjCzAPpgVioda25qQzSiEiadh3cf2veAxoXd0q6T5CsEu53EXhHHxhyBSzik+6h 2JoeHvwaMJCZy4GNum8woC6+2S63DHblqIfr0e/ai0GpamwVwNVxOy0W7e94Xhb0xGze wwk2h0+x97i2FcBhwNOGu+pQIPEMRmO/3zIetKozo1b8h/ds2jZZ+7lJDEkSYkZ6ax5K pD67i52oDtAKf6yADbVv48D6Q8FgqtRNJGHwxvVWFzzPUeRK5VIfoA0A8z/39hs+zVL+ sSDB+pkuJ7PMKVmHOBFncbX9b1WbM6K8US4Qp4wvwVm2/B0rltRs00UFBtCZ7bFZ8uoR BeLQ==
X-Gm-Message-State: APzg51CUiSh4eL71tnoXRCg9CoWyBZCgUe1eyuD3qAPPkIHqifH+dof9 cNzRZ1CoNXnX6CZ/9Lbn+UXvfWmPZ3vcqCPwU3c=
X-Google-Smtp-Source: ANB0VdbLzQJuwjAXCW2psIBwsTCyBXPSAgbGjQi7VWIgS9h/7u/ICkRiLGNOeUJD7Rx02pxnAlxbCFqfKWdhcZVyV3Q=
X-Received: by 2002:aca:5043:: with SMTP id e64-v6mr1655487oib.111.1537281953605; Tue, 18 Sep 2018 07:45:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4a:8927:0:0:0:0:0 with HTTP; Tue, 18 Sep 2018 07:45:23 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Ted Hardie <>
Date: Tue, 18 Sep 2018 07:45:23 -0700
Message-ID: <>
To: Gaurav Jain <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="000000000000c3afaa0576265826"
Archived-At: <>
Subject: Re: [Uri-review] Wi-Fi Alliance permanent scheme registration - review request
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proposed URI Schemes <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 18 Sep 2018 14:45:58 -0000

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,


Ted Hardie

On Mon, Sep 17, 2018 at 1:14 PM, Gaurav Jain <> 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 (
>    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
> Visit our blog, The Beacon <>, for Wi-Fi
> industry topics and trends
> _______________________________________________
> Uri-review mailing list