Re: Lastest drfat of RFC-XXXX

[Craig_Everhart@xxxxxxxxxxxx]

Off-the-cuff comments, admitting that I wasn't at IETF to argue the points.

I believe that it should be made clear that the agent selecting a
``cookie'', even one that begins with two hyphens, needs to ensure that
the cookie doesn't appear anywhere in the encapsulated parts of a
message, not simply that it does not appear at the beginning of any of
the lines in the encapsulated parts.  This is what makes it work in the
presence of folded lines.

``Dash-count:'' seems abstruse, and should be subject to the same
analysis that RFC934 hyphens did.  What happens if there's a Dash-count:
of 62 and lines get wrapped by a mailer at 50 columns?  What happens
with an ordinary wrap-at-128-columns mailer if there's a Dash-count: of
12 and an unintentional sequence of 12 dashes happens to get wrapped to
the beginning of a line?

(Why are we calling them dashes when they're called hyphens?  A typist
generally renders a single written dash by typing two or three hyphens.)

Aren't the non-cookie methods of encapsulating messages simply asking
for trouble?

In addition to the perversions that RFC-XXXX says that MTAs perform on
messages, they can also add or remove spaces at ends of lines.

Wouldn't a G3FAX message better be encoded as
	Content-type: G3Fax
	Content-encoding: ASN.1, base64
rather than
	Content-type: ASN.1; whatever; G3Fax
	Content-encoding: base64
That is, doesn't it make more sense to have Content-type: refer to the
innermost underlying structure, and use Content-encoding: for all the
encoding rules?

		Craig