Please tackle the Right Thing

[André Colomb]

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 <andre at colomb.de>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20210120/0e5aa843/attachment-0001.sig>