Subject: Review of draft-ietf-httpbis-bcp56bis-09

From: Cullen Jennings <[email-masked]>
Date: Wed, 20 Nov 2019 17:39:43 +0800

I do not think the document is ready to publish. 

Let me take the example of an spec defining an API to get an random number 

Lets say I have registered the ./well-known/fluffy space and I want to define a protocol for IOT devices to get a random number that changes each day by doing a GET of https://example.com/.well-known/fluffy/v1/rand (and the spec for this has all the appropriate info about catch control etc ) 

It seems like the last paragraph of 4.4.1 says this is allowed. I think this example is illustrative of the main things people have been complain with about the BCP 56 (the current version, not the bis draft here ) 

Let us start by if we agree the above is allowed or not. If I am wrong that this is not allowed, then ignore the rest of this email and we can talk about why it is not allowed. 

Section 4.4.1 of the drafts say 

   Applications MUST NOT define a fixed prefix for its URL paths; for
   reasons explained in [RFC7320], this is bad practice.

This seems wrong and needs to call out the exception for the .well-known space 

Section 3.2 seems to forbid the .well-known space at all so I think this section needs to specifically mention and carve out the .well-known space. 

Section 4.4, last paragraph - This seems not true for example above so this seems wrong 

Section 4.4.1 says 

   The most straightforward mechanism for URL discovery is to configure
   the client with (or otherwise convey to it) a full URL.  This might
   be done in a configuration document, in DNS or mDNS, or through
   another discovery mechanism.

What's the advice on how to do the full URL in DNS ?

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 21 Nov 2019 08:39:55 +0800

> This seems wrong and needs to call out the exception for the .well-known space 

Yes, this seems to be making a stronger and less-nuanced statement than 7320[bis].  It might instead be better to avoid using 2119 language here and instead cite 7320bis.

> Section 3.2 seems to forbid the .well-known space at all so I think 
> this section needs to specifically mention and carve out the 
> .well-known space. 

I don't see a specific problem here, though your suggestion to mention .well-known is definitely worth considering.  However, I don't think that we need to encourage the use of that space.  I would prefer to discourage it instead.

> Section 4.4, last paragraph - This seems not true for example above so 

Yes, this is a little strong, though I would still prefer to add a bias against use of .well-known.

> What's the advice on how to do the full URL in DNS ?

RFC 7553?  DDDS?  TXT? Bespoke RRtype?  I don't think that we have consensus on the right approach, but there do seem to be plenty of options that don't rely on the narrow path from name to URL that .well-known enables.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 21 Nov 2019 08:44:43 +0800

Hi Cullen,

> On 20 Nov 2019, at 5:39 pm, Cullen Jennings <[email-masked]> wrote:
> 
> It seems like the last paragraph of 4.4.1 says this is allowed.

It is.

> I think this example is illustrative of the main things people have been complain with about the BCP 56 (the current version, not the bis draft here ) 

Honestly, I don't know that people have thought about or referred to the original BCP56 for several years, but OK. (Are you thinking about 7320, perhaps?)

> This seems wrong and needs to call out the exception for the .well-known space 

It is excepted in the next statement, starting with "Instead, a specification for such an application..."

If you're saying that the link between these sentences isn't strong / obvious enough, I'm happy to take that as editorial feedback.

> Section 3.2 seems to forbid the .well-known space at all so I think this section needs to specifically mention and carve out the .well-known space. 

3.2 doesn't forbid anything; it's explaining a pattern for use that gets utility out of HTTP. 

(I'm starting to wonder which revision of the draft you looked at; some of this changed in -09)

That paragraph in -09 is:

> Therefore, the specification writer needs some mechanism to allow clients to discovery an application's URLs.  Additionally, they need to specify what URL scheme(s) the application should be used with, and whether to use a dedicated port, or reuse HTTP's port(s).

Can you explain why this isn't true for your example?

> What's the advice on how to do the full URL in DNS ?

I don't know that the HTTP WG should give advice about how to do things in DNS. If there's a consensus way to do this, we can refer to it -- but the intent here was to have a hanging reference for others (including application authors, if need be) fill in.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 28 Nov 2019 16:19:25 +1100

Fluffy and I had a chat in Singapore and clarified the underlying issues here; I've just pushed:
  https://github.com/httpwg/http-extensions/commit/c804422494
to address his concerns.

Cheers,

> On 21 Nov 2019, at 11:44 am, Mark Nottingham <[email-masked]> wrote:
> 
> Hi Cullen,
>