OPEN ISSUES IN RFC-XXXX
A. 2: Checksums: There seems to be a consensus that we should have checksum
s,
but no consensus on the mechanism, applicability, or level of requirement.
I like the analysis Dave C. suggested. Checksumming of Base 64 is an
independent issue, and should be included.
A. 3: Non-ASCII Headers. The Keith Moore proposal, in particular.
Should it be part of RFC-XXXX?
As I stated with my chairman's hat on earlier, this will be a separate
document. IF it is ready at the same time as RFC XXXX, the two
documents can be published as a set. The two documents cover
different issues, and may evolve independently.
B. 1: Where are PostScript, TeX, and Troff?
Unless a good usage statement for TeX and Troff is provided before
Santa Fe, these content types shouldbe dropped. Elements to be
documented include Security, Macro Packages, Style files etc.
B. 6: Character sets.
B. 8: Incomplete "character sets" -- How to handle 2022, 10646, MNEMONIC
We agree that ISO 2022 as use by our Asian friends is not a character
set. It is a mechanism, and as such should be designated a text
subtype which reflects it's current usage. Same applies for NMONIC.
With a good write-up of necessary parameters, this should be included.
Keld-Mark? It is not possible to write a good profile of 10646 at
this time and it should be skipped.
B. 14: Trojan horses in mail
As I have stated, we do not need to design security, but we need to
document known problems.
Greg Vaudreuil