Change Details

https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-08#page-4 says: There are two variants on how to form the request URI: The advanced and the direct method. Implementations MUST first try the advanced method. Only if the required sub-domain does not exist, they SHOULD fall back to the direct method. But it's not clear what "the required sub-domain does not exist" means exactly. I can imagine several different implementations/interpretations: 0) is there no DNS record at all at openpgpkey.example.org? 1) does a DNS query for A records for openpgpkey.example.org return an assertion of non-existence? 2) does a DNS query for A or AAAA records for openpgpkey.example.org return an assertion of non-existence? 3) are all of the A or AAAA addresses returned from such a query (after following CNAMEs) unreachable on the network? 4) if one is reachable, but port 443 is closed? 5) if port 443 is closed, but the TLS handshake authentication fails? 6) if the TLS connection completes, and an HTTP request can be sent, but the response is not an HTTP response? 7) if the HTTP response does not return 200 for the specific lookup? 8) if the 200 HTTP response is not a series of OpenPGP certificates? I *think* that (2) above is the right trigger for the fallback, but i'm not sure exactly how to implement it in many HTTP client libraries that abstract away the specific failures. i'm also not exactly sure how to implement it when connecting through a SOCKS5 proxy or other situation where as a client i don't have access to the DNS queries directly. Perhaps a concrete example about how/when to fallback would be a useful contribution to the doc?

https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-08#page-4 says: There are two variants on how to form the request URI: The advanced and the direct method. Implementations MUST first try the advanced method. Only if the required sub-domain does not exist, they SHOULD fall back to the direct method. But it's not clear what "the required sub-domain does not exist" means exactly. I can imagine several different implementations/interpretations: 0) is there no DNS record at all at openpgpkey.example.org? 1) does a DNS query for A records for openpgpkey.example.org return an assertion of non-existence? 2) does a DNS query for A or AAAA records for openpgpkey.example.org return an assertion of non-existence (following CNAME records, if found)? 3) are all of the A or AAAA addresses returned from such a query (after following CNAMEs) unreachable on the network? 4) if one is reachable, but port 443 is closed? 5) if port 443 is not closed, but the TLS handshake authentication fails? 6) if the TLS connection completes, and an HTTP request can be sent, but the response is not an HTTP response? 7) if the HTTP response does not return 200 for the specific lookup? 8) if the 200 HTTP response is not a series of OpenPGP certificates? I *think* that (2) above is the right trigger for the fallback, but i'm not sure exactly how to implement it in many HTTP client libraries that abstract away the specific failures. i'm also not exactly sure how to implement it when connecting through a SOCKS5 proxy or other situation where as a client i don't have access to the DNS queries directly. Perhaps a concrete example about how/when to fallback would be a useful contribution to the doc?

https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-08#page-4 says: There are two variants on how to form the request URI: The advanced and the direct method. Implementations MUST first try the advanced method. Only if the required sub-domain does not exist, they SHOULD fall back to the direct method. But it's not clear what "the required sub-domain does not exist" means exactly. I can imagine several different implementations/interpretations: 0) is there no DNS record at all at openpgpkey.example.org? 1) does a DNS query for A records for openpgpkey.example.org return an assertion of non-existence? 2) does a DNS query for A or AAAA records for openpgpkey.example.org return an assertion of non-existence (following CNAME records, if found)? 3) are all of the A or AAAA addresses returned from such a query (after following CNAMEs) unreachable on the network? 4) if one is reachable, but port 443 is closed? 5) if port 443 is not closed, but the TLS handshake authentication fails? 6) if the TLS connection completes, and an HTTP request can be sent, but the response is not an HTTP response? 7) if the HTTP response does not return 200 for the specific lookup? 8) if the 200 HTTP response is not a series of OpenPGP certificates? I *think* that (2) above is the right trigger for the fallback, but i'm not sure exactly how to implement it in many HTTP client libraries that abstract away the specific failures. i'm also not exactly sure how to implement it when connecting through a SOCKS5 proxy or other situation where as a client i don't have access to the DNS queries directly. Perhaps a concrete example about how/when to fallback would be a useful contribution to the doc?