Hi all, after some more thought I came up with a possible wording to clarify the fallback behavior. Assuming that an opportunistic approach is preferred, so the direct method should be used not only based on the existence of openpgpkey as a SRV or other record. Here goes:
---SNIP--- (page 3, second paragraph in the current draft version 11) There are two variants on how to form the request URI: The advanced and the direct method. Implementations MUST first try the advanced method. If that does not conclude with a successful HTTP response (e.g. status code 2xx), they MUST fall back to the direct method. If the required sub-domain exists, but other errors occur during the connection, they SHOULD output an error message pointing out the failure reason to the end user. Such other errors include, for example, invalid, expired or misconfigured TLS certificates and HTTP failure codes (4xx or 5xx). ---SNIP--- The last "SHOULD" clause would allow for Sequoia's current behavior to silently switch over, but shows what the Right Way would encompass. Regarding GnuPG, the second "MUST" clause requires a change to fall back after later connection errors. I think that this logic still holds just in case SRV records are to be used again. So what do you think? I'm not subscribed to any IETF mailing lists, but feel free to propose this in the relevant circles. I hereby renounce my rights on the modified text :-) Kind regards André -- Greetings... From: André Colomb <an...@colomb.de>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
