- From: Martin Thomson <mt@lowentropy.net>
- Date: Thu, 21 Nov 2019 08:39:55 +0800
- To: ietf-http-wg@w3.org
On Wed, Nov 20, 2019, at 17:39, Cullen Jennings wrote: > 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 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 > this seems wrong Yes, this is a little strong, though I would still prefer to add a bias against use of .well-known. > 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 ? 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.
Received on Thursday, 21 November 2019 00:40:17 UTC