-----BEGIN PGP SIGNED MESSAGE-----
In <slrn650mp9(_dot_)li(_dot_)lutz(_at_)taranis(_dot_)iks-jena(_dot_)de>, on
10/24/97
at 08:24 AM, lutz(_at_)taranis(_dot_)iks-jena(_dot_)de (Lutz Donnerhacke)
said:
* William Allen Simpson wrote:
I just caught up on the armor argument, and suggest that ASCII armor and
MIME are presentation issues, not message element issues.
Therefore, they should be in separate documents from the binary message
elements. A MIME conformant implementation will not necessarily
implement Armor, and vice versa.
MIME encording is currently and will be seperated. IMHO Ascii Armor
should not be seperated, because it should not be used as independend
layer for messages. Yes, it may contain a literal packet, but it can not
contain a complete other level seven content.
But your comment is correct. I will move the 3.2 description to the
beginning of 5 to support layering.
Note to the editor, could you please standardize on the term "element"
or "message element" instead of "packet". A packet has a well-known
networking definition.
Currently this draft defines: "The octet stream of a PGP message is
seperated into a several chunks. They are called packets."
The term "packet" is used by the Ascii Armor and well known to the
public. Should we exchange it?
The term "packet" is a well known and well defined in the PGP comunity. I
see no reason for changing this now. I see little chance of a PGP "packet"
and a network "packet" being confused for one or another as we are
describing document formats here not network protocols.
- --
- ---------------------------------------------------------------
William H. Geiger III http://www.amaranth.com/~whgiii
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 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html
- ---------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: cp850
Comment: Registered_User_E-Secure_v1.1b1_ES000000
iQCVAwUBNFBh3o9Co1n+aLhhAQEQ3AQAjINw+uPcL2xoVqT1zVI4NBD7uYoMdwcM
eFoegAYliVQyGtzyY3tNtmRwPwcYAGVe01mEL5WbDl8XUIwROV29lfKEZONIQAWo
Fns5K/HfkGloXLnpvWFKj4pyB5kVETSbvlx6uoaXgsw24esWd45NcmGLEM9PEV6B
K8JS6WUhIIU=
=KHlA
-----END PGP SIGNATURE-----