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

[Mark Nottingham <[e-mail]>]

Hi Cullen,

> On 20 Nov 2019, at 5:39 pm, Cullen Jennings <[e-mail]> wrote:
> 
> 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.

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


> 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 

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)


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

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?


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

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/