ietf-822
[Top] [All Lists]

Re: Transport Encodings

1991-09-11 08:10:03
Greg,
  I think this is very useful, but, for me at least, it tends to 
reinforce the view I was trying to feel out in a message that probably 
crossed yours in the redistribution pipe this morning.
  I guess the summary of that message, when your taxonomy is applied to 
it, is "let's simplify this story by having the sender specify the 
conversion directly, rather than working up an intermediary typology 
through which the conversion can be deduced.
  In that system, your five cases collapse into three: none, 
quoted-printable, and base64, with a clear extension to "don't convert" 
if anyone but me (and Stef, probably) still think that should be 
offered.

  I'm also, personally, back to ignoring the "binary, no line length 
transport" question.  Several reasons have been identified why this is 
not a good idea, at least without additonal safeguards.  One subset of 
the class of safeguards probably requires PEM, which means (as I 
understand it) at trip through Base64 anyway, so there is no point 
considering those cases as no-line-length binary.  It has also been 
pointed out that a "binary" message in RFC-XXXX format (or, more 
generally, with any form of vaguely RFC822-compliant text headers) 
is going to need processing and extraction--it isn't going to be like 
FTP or BITNET NETDATA, which can be used "right off the wire" as 
received.

Several people have said, more or less "we wanna have binary transport"
and others have said "we know how to do binary transport".  I think the
latter is clear, and people are certainly entitled to their preferences.

But, given the objections that have been raised and the fact that this 
does make things slightly more complex and increases the number, and 
possibly severity, of failure cases (i.e., it is an interoperability 
threat), I'd like to see this dropped until some of the advocates can 
come forward and say "we *need* binary transport because...", or "the 
savings in bandwidth are really important because...".

It is possible, for example, that we could meet the real need for
"binary 8 bit transport" with the "enclave-only, no conversion" model
that the WG decided was inappropriate for "mail".  I'd like an
opportunity to think about those cases.  That is not an opportunity I 
have as long as the "binary requirement" is expressed without technical 
justification and a real statement of purpose.
   --john

<Prev in Thread] Current Thread [Next in Thread>