Re: [Uri-review] Proposed scheme registration: sdns (DNS stamps)

Hi Frank,

Thanks for sending the proposal to the list.  A couple of high level
comments.

First, the syntax you present uses //, which doesn't seem to be correct to
me.  If I'm reading the specification correctly, the URL doesn't have a
hierarchical part and does not rely on an authority section (which is what
the // delimits in RFC 3986 syntax).

2nd, it's not clear in the description of addresses how they would be fed
into the algorithm you provide in some of the corner cases.  For example:

"addr is the IP address of the server. It can be an empty string, or just a
port number."  Is the port number represented with a preceding colon?

For IPv6 hosts which use [ and ] as delimeters, is the input URL-encoded
before being base64 encoded?  Are scopes permitted?

For hostname, the document says  that hostname is the server host name
which will also be used as a SNI name.  If the hostname uses one of the
IDNA characters outside the URL-permitted range, is it encoded with URL
encoding or punycode?

As a stylistic note, I think sdns is likely to be confused with the
existing dns scheme name, and I would suggest using "dns-stamps" for
additional clarity.

Thanks again for the opportunity to comment,

Ted Hardie

On Wed, Oct 24, 2018 at 9:00 AM Frank Denis <ietf=
40dnscrypt.info@dmarc.ietf.org> wrote:

> Scheme name: sdns
>
> Status: Provisional
>
> Applications/protocols that use this scheme name: stub DNS resolvers and
> DNS proxies
>
> Contact: Frank Denis <ietf@dnscrypt.info>
>
> Change controller: Frank Denis <ietf@dnscrypt.info>
>
> References: https://dnscrypt.info/stamps-specifications/
>
> Scheme syntax: sdns://<base64 encoded parameters>
>
> Scheme semantics:
> The scheme is used to encode parameters required for a DNS client to
> securely connect to an upstream server, in a protocol-independent way.
>
> Encoding consideration:
> URIs are guaranteed to only contain characters from the URL-safe variant
> of Base64.
>
> Interoperability considerations: None
>
> Security considerations:
> Clients must verify the authenticity and integrity of URIs before using
> them.
>
> _______________________________________________
> Uri-review mailing list
> Uri-review@ietf.org
> https://www.ietf.org/mailman/listinfo/uri-review
>