-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ian touched on many of the salient points of this dilemma. The most
correct answer to the problem you pose is "mu."
This is something that you have to make a personal decision on.
Let's suppose that the standard said something definitive on this.
Many people have gotten into a lot of trouble by over-implementing
standards. Let's suppose, for example, that you reject the key. Let's
then suppose that someone finds that they can't import in keys that
were created with software X on OS Y with a key size of a prime
number of bits.
Well -- what do you do? There are people who want to use your code
and can't, and it's not your fault. Screw 'em, they're the ones who
got the standard wrong.
But when it turns out that the problem is that your software doesn't
work with the new OpenPGP in Linux that runs underneath Windows
Mobile Horizon that ships in the new Apple iTunesFone (when it
creates keys 1987 bits long (selected because it's a prime number
*and* the year programmer's GF was born -- cool, huh?)) and because
of it, people can't download music from WalMart's GNU Music Share --
well, the story on Slashdot is going to have *your* software's name
on the headline, not theirs. You'll be changing your code to ignore
that one extra byte because otherwise every phone in Korea has to be
re-flashed, and it's faster for you to change than them. (Something
similar to this happened to PGP once, but I changed the name of the
country in my explanation.)
An alternative to just accepting that packet would be to lop off the
extra data (which will be ignored), and make the length correct.
When you implement a protocol, there are often more choices than
being anal or passing idiocy through. In the one you've given, it's
almost certainly true that you can tweak the packet to the right size
and not affect anything else. So why not do so?
It might also be a good thing to tell the people who are doing
something dumb that they're doing something dumb, but don't expect
them to fix it tomorrow, especially since there's a workaround. When
it's been a couple of years and no fix has arrived, you have earned
the right to be snarky, but by then you probably forgot the
workaround you put in your code, too.
As for your second question -- where partial lengths can be used --
what's your real question? Do you want to use them in places other
than data packets? Is someone subjecting you to them and it's a pain
in the neck to parse them?
It's Sunday afternoon and I need to run some errands, so I don't want
to go crawl through the spec. I *believe* that they can be used
anywhere. But I also believe they shouldn't be used everywhere. In
the case of a 400-byte packet header, whatever would possess someone
to do that? Yeah, I'm sure it's legal, but don't do it. If it's the
software I'm responsible for that's doing something cringe-worthy,
I'm sorry.
Partial lengths exist so that you can process arbitrarily large
chunks of data that don't fit in memory and might even be
inconvenient for you to know the size of a priori. That really means
data packets. However, as a software engineer, I think that even if
some idiot chopped up a 400-byte key packet into 2-byte partials,
your software ought to work. If it doesn't, you have to consider who
the idiot is. That brings us back to the original consideration.
Welcome to being a software engineer. Sometimes the things we have to
do because other people are idiots suck. A sense of humor helps deal
with it, but doesn't prevent it from sucking.
Jon
-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 2.5.2
Charset: US-ASCII
wj8DBQFFoYiZsTedWZOD3gYRAjbyAJwLiOgAYYHSjANqhkaPDpKZ9V1b8QCgpFr3
eLbCx4/y6vWM8hIeqYHNh9k=
=jbmi
-----END PGP SIGNATURE-----