Jean-Marc Desperrier wrote:
Dave Crocker writes :
If this is is an example of the way discussions have gone on usefor,
then
it's pretty clear why the technical work is in trouble.
The current usefor text is very technically sound .
Actually, no. Please see the discussions about gateways and RFC 2047
on the ietf-822 archives. Summary: the Usefor draft is technically flawed;
it requires gateways to do the impossible.
You might not like the direction where it goes, but there has been a lot
of serious work on every aspect.
Much is at best experimental, and often untested. Sometimes not even
clearly thought out.
3. the logic behind that goal is applicable to any other application
having
a similar installed base history.
The big difference is that Usenet transport has almost since the very
start been fully 8 bit.
Now that is an example of the way discussions have gone on usefor. Dave
wrote about the logic behind the goal of compatibility with installed
base (including moderation methods, combined user agents, etc.). Suddenly
there's an abrupt change of topic to "Usenet has always had 8-bit clean
transport". Whether or not that statement is factually correct is being
addressed by others, I see. My point is that the issue isn't solely about
transport. Compatibilty is also about user agent software, moderation
methods and software, etc.
7. breaking standards is not measured by whether someone's code
core-dumps.
it is measured by whether it violates the specification. sending
8-bit data
in a 7-bit environment breaks the specification. sending valid
strings of 7-bit
data that might need further interpretation (to obtain the semantics)
does
not.
Usenet is a 8 bit environnement.
No Usenet necessarily uses email for moderation, and there are established
prohibitions against 8-bit data in headers (incidentally, that also applies
to news, as RFC 1036 uses the same message format with the same header content
restrictions). Once again, there is confusion between transport and the larger
scope of compatibility in toto.