[openpgp] Re: HKP draft TODO items

--===============8629991382371908015==
Content-Type: multipart/alternative; boundary="0000000000000e47fa06528876d3"

--0000000000000e47fa06528876d3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Andrew,

Thanks for opening these so quickly. I took a first pass through !7, !8,
and !9.

On the 400 versus 404 question: the main case I had in mind is client
diagnostics and interoperability testing, not discovery of server contents.

If the path is syntactically invalid, say a missing version component, a
non-hex character, an odd-length fingerprint, or a component with the wrong
length, a 400-class response lets a client distinguish =E2=80=9CI built the=
 request
wrong=E2=80=9D from =E2=80=9Cthe request was well formed but did not match =
anything.=E2=80=9D It
also makes conformance tests cleaner, because malformed-path tests can have
a clear expected outcome that is separate from normal negative lookup tests=
.

By contrast, if the request is syntactically valid but there is no matching
certificate, 404 seems like the right result. I would also be comfortable
treating a syntactically valid but unsupported key version as a lookup
miss, unless the draft wants to make unsupported-version handling more
explicit.

I would not make this a hill to die on. A SHOULD-level rule, or even a
short implementation note, would be enough. For example:

A keyserver SHOULD return 400 Bad Request for syntactically invalid v2
lookup paths, such as malformed hexadecimal components or
version/fingerprint components of the wrong length. A syntactically valid
lookup that has no matching result SHOULD be treated as a lookup miss.

!7 looks consistent with the intent of making the Legacy API normative only
for implementations that explicitly support it.

!9 also looks good overall. Two small things to check:

   - for the new application/pgp media type, should the IANA template
say Encoding
   considerations: binary rather than none, since the type is defined for
   binary OpenPGP data?
   - for the updated application/pgp-keys registration, Interoperability
   considerations: none may be a little strong given the mixed-keyring
   compatibility discussion nearby. It might be enough to point back to tha=
t
   section, or mention that legacy implementations may vary in how they
   process detached revocations.

Happy to take another look once the JSON response text or examples land.

Best,

Songbo Bu

--0000000000000e47fa06528876d3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><p>Hi Andrew,</p>
<p>Thanks for opening these so quickly. I took a first pass through !7, !8,=
 and !9.</p>
<p>On the 400 versus 404 question: the main case I had in mind is client di=
agnostics and interoperability testing, not discovery of server contents.</=
p>
<p>If the path is syntactically invalid, say a missing version component, a=
 non-hex character, an odd-length fingerprint, or a component with the wron=
g length, a 400-class response lets a client distinguish =E2=80=9CI built t=
he request wrong=E2=80=9D from =E2=80=9Cthe request was well formed but did=
 not match anything.=E2=80=9D It also makes conformance tests cleaner, beca=
use malformed-path tests can have a clear expected outcome that is separate=
 from normal negative lookup tests.</p>
<p>By contrast, if the request is syntactically valid but there is no match=
ing certificate, 404 seems like the right result. I would also be comfortab=
le treating a syntactically valid but unsupported key version as a lookup m=
iss, unless the draft wants to make unsupported-version handling more expli=
cit.</p>
<p>I would not make this a hill to die on. A SHOULD-level rule, or even a s=
hort implementation note, would be enough. For example:</p>
<blockquote>
<p>A keyserver SHOULD return 400 Bad Request for syntactically invalid v2 l=
ookup paths, such as malformed hexadecimal components or version/fingerprin=
t components of the wrong length. A syntactically valid lookup that has no =
matching result SHOULD be treated as a lookup miss.</p>
</blockquote>
<p>!7 looks consistent with the intent of making the Legacy API normative o=
nly for implementations that explicitly support it.</p>
<p>!9 also looks good overall. Two small things to check:</p>
<ul>
<li>for the new <code>application/pgp</code> media type, should the IANA te=
mplate say <code>Encoding considerations: binary</code> rather than <code>n=
one</code>, since the type is defined for binary OpenPGP data?</li>
<li>for the updated <code>application/pgp-keys</code> registration, <code>I=
nteroperability considerations: none</code> may be a little strong given th=
e mixed-keyring compatibility discussion nearby. It might be enough to poin=
t back to that section, or mention that legacy implementations may vary in =
how they process detached revocations.</li>
</ul>
<p>Happy to take another look once the JSON response text or examples land.=
</p>
<p>Best,</p>
<p>Songbo Bu</p>
</div>

--0000000000000e47fa06528876d3--


--===============8629991382371908015==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18Kb3BlbnBncCBt
YWlsaW5nIGxpc3QgLS0gb3BlbnBncEBpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVt
YWlsIHRvIG9wZW5wZ3AtbGVhdmVAaWV0Zi5vcmcK

--===============8629991382371908015==--