-----BEGIN PGP SIGNED MESSAGE-----
In
<3(_dot_)0(_dot_)3(_dot_)32(_dot_)19980908113511(_dot_)0090fc40(_at_)mail(_dot_)pgp(_dot_)com>,
on 09/08/98
at 11:35 AM, Jon Callas <jon(_at_)pgp(_dot_)com> said:
You are indeed correct that it's a faux pas that it uses 17 for the
packet id and not something in the 60-63 range. I argued the same thing
here at NAI, but I lost that debate. I discussed it with John Noerenberg,
who agreed that it was a faux pas, but not a big one -- especially given
that the WG consensus was that there should be an implementation first.
Nonetheless, I agree with you on *that* part of it wholeheartedly. The
NAI developers are running the risk that OpenPGP 1.1 will define non-text
user ids to be something incompatible with what they did for PGP 6, and
they'll have to adapt.
The PGP developers argued that they should not use the experimental range
because doing so would de-facto use up that opcode because of all the
copies of PGP 6 that would use it. I see their point, but I diagree.
Just to make things clear, I do not have a problem with NAI comming up
with something new for PGP, nor do I expect them to come to the WG for
permission to do so. My biggest objection was the grabbing of an
unassigned packet id without telling anyone about it. Now myself and
everyone else have to re-write their code to take these new packets into
account (any keys that I encounter with an unassigned packet id are
assumed to be in error and are rejected). Not major, but a PITA non the
less (FWIW I will be writting a patch for 5.0i when I have some free time
unless someone else feels up to it).
I really think that we need to establish some type of informal mechanism
for assigning numbers (packet, hash, algorithm, ect...) to prevent
problems in the future. I fear that things can get very ugly if we have 4
or 5 different vendors start using unassigned numbers whenever they have
something new to add.
Now as far as PhotoID's and ID's in general. I have mentioned in the past
for having some type of generic ID format that contained a type flag so
applications could invoke some type of sanity checking.
So lets say we have packet type 20 -- Generic ID. Then in the type field:
01 -- RFC822 E-Mail address
02 -- Real Name
03 -- Address
04 -- URL
05 -- X.500
10 -- PhotoID
15 -- Fingerprint
30 -- Retinal Scan
... ect
This seems to be a more sane approach than having a seperate packet type
for each ID format.
- --
- ---------------------------------------------------------------
William H. Geiger III http://www.openpgp.net
Geiger Consulting Cooking With Warp 4.0
Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
- ---------------------------------------------------------------
Tag-O-Matic: Air conditioned environment - Do not open Windows.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a-sha1
Charset: cp850
Comment: Registered_User_E-Secure_v1.1b1_ES000000
iQCVAwUBNfWG+Y9Co1n+aLhhAQHw9wP/RGr32CxDvsFdiLbpH2I2GMoisoPhTHWa
O8H0GqZbwCW2B7UhvB+YtvINWRP7jstWS1XmzdgInxnU/53XZFRrRkzMKOFZpUMy
0GzS9fhxK3BBAVa4LnFe8Ew8jxa/NCKqe/JNi3hXLBpTIX/hfUt3+T+gZq6SW9CM
124U6jEAzZg=
=C6pq
-----END PGP SIGNATURE-----
Tag-O-Matic: To whom the gods destroy, they first teach Windows...