Review of draft-ietf-httpbis-bcp56bis-09

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 ?

Received on Wednesday, 20 November 2019 09:39:53 UTC