Charles Lindsey wrote:
In <38167744153(_dot_)20030107093025(_at_)brandenburg(_dot_)com> Dave Crocker
<dcrocker(_at_)brandenburg(_dot_)com> writes:
To add to Ned's correction, news-> email gatewaying has been around for at
least 20 years, as far as I can recall. Organizations have often wanted to
plug mailing lists into newsgroups. To permit the newsgroup readers to
participate in the mailing list, a news->email gateway is required. In other
environments, the 2-way gatewaying is simply part of a model that lets users
decide how they want to receive and process their group discussion messages.
Yes indeed, but those are not GENERAL-PURPOSE gateways. They only have to
be capable of meeting the needs of the newsgroup and the community of
users they were designed to serve. That is a simpler problem than a
gateway that will take any article whatsoever out of Usenet and produce a
compliant email out of it.
Surely if the Usefor draft as it is currently formulated will have dire
consequenses for limited-purpose gateways, general-purpose gateways will
be at least as adversely affected.
With respect to the appearance of new capabilities (such as new data formats
and encodings) in the installed base, your use of the term "gobbledegook"
needs to be made more precise. If it means that that a legacy system
receives the data and the data are legal but meaningless -- MIME base64 is
example of this approach -- then it is fine. It permits incremental adoption
without breaking existing systems. The downside for existing systems is that
they do not get the benefit of the new feature, but everything else
continues to work fine.
Yes, that is exactly what I mean. If someone in the newsgroup suddenly
starts using raw UTF-8 in his name (a phrase) or in his Subject, the
existing gateway is unlikely to fall over and collapse.
But that is *not* what the above quoted part of Dave's message says;
rather it corresponds to his text:
"If it means that the legacy system receives data that are illegal, with
respect to the existing service, then this is not at all fine.
Interoperability requires conforming to a standard, rather than conforming
to it whenever it is convenient. Injecting illegal data is not conforming.
"
> But it will surely
pass on something that has been munged, or will be munged when it arrives
at some User Agent as a mail to be displayed. So the reader will see
something that is obviously not correct (hence my use of the term
"gobbledegook"). It will stick out like a sore thumb. So the sky does not
fall in, but you do not get the benefit of the new functionality.
No, there simply is no new functionality -- indeed there is significanly *less*
functionality compared to 2822 + MIME, as RFC 2047/2231 encodings provide
charset tags and language tagging, which obviously raw (i.e. untagged) utf-8
encoding does not. And since utf-8 is only a charset as far as this use is
concerned, anything that could potentially be done in those header fields with
raw utf-8 could instead be done in a standards-compliant, interoperable,
compatible manner by using RFC 2047 encoding, tagged with the charset "utf-8",
and optionally tagged with a language tag.
So what happens? Perhaps they say "This is an English speaking group; why
are these people trying to inflict a foreign language on us?". Not a very
polite response, but Usenet is not always a very polite place :-( .
More likely they'll say "use the standard RFC 2047 encoding", and in the case
of Subject field, "please use a language tag".
Or else they say "There are only a few posters doing this, and even though
we cannot decipher their names, their email addresses are still OK, and
their Subjects have a few odd characters, but we can work out what is
going on from the bodies". And so they tolerate the small amount of stuff
coming through.
Or else they say "We should be using this new functionality, and the
amount of it is likely to increase. So we will ask our gateway
administrator to upgrade in line with the new standard".
But *there is no new functionality*! So in this case, gateway administrators
would be pestered for no good reason.
So, gradually, the new functionality is seen throughout the net, starting
with the places where it is most needed.
But *THERE IS NO NEW FUNCTIONALITY*!!
If it means that the legacy system receives data that are illegal, with
respect to the existing service, then this is not at all fine.
Interoperability requires conforming to a standard, rather than conforming
to it whenever it is convenient. Injecting illegal data is not conforming.
You will only get data that are illegal with respect to the existing
service if someone is trying to use the new funtionality.
Bullshit! Tere is no new functionality.
Infrastructure changes rarely permit incremental upgrade. Hence, a change to
the infrastructure often must be done to the *entire* infrastructure before
there can be benefit to any users.
The main advantage that Usenet has over email is that is main
infrastructure - the backbone of relaying agents that carry it worldwide -
is already capable of supporting UTF-8 (indeed any charset) in headers.
Hence the cost of the new functionality need only be born by those who
want to use it - namely the users who may need to upgrade their
newsreaders in order to see the benefits. There are some problems with
moderators, which we have carefully addressed, and some issues with
gateways, as I have described above.
Once again, there simply is no new functionality involved w.r.t the examples
given here. The existing Usenet transport is also fully capable of supporting
standard (i.e. RFC 2047/2231) encoding mechanism (as opposed to raw utf-8
encoding), which has functionality which would be removed. And the most widely
used newsreaders are in fact combined mail user agents / news readers, which
already support RFC 2047/2231 (yes, there are some bugs). The Usefor draft's
requirement of raw utf-8 encoding means not only that gateways will have to
be substantially modified (and in fact some of the proposed changes are not
possible to implement), but it causes difficulty for moderators and news
system administrators, and would require those combined mail user agent/ news
reader programs to be modified as well -- with absolutely no new functionality
except for extended newsgroup component tags (which could be implemented by
a variety of standards-compliant, backward-compatible, interoperable
mechanisms). Given the importance of email to commerce (vs. the negative
commercial impact of supposed "workers" wasting their employers' time on
Usenet during business hours), in fact what is likely to happen is that
what are now combined mail user agents / news readers will likely drop support
for news -- it is simply not worth turning the entire world upside down
because a handful of individuals dislikw RFC 2047. Moreover the infrastructure
of Usenet includes the email infrastructure, since Usenet *requires* use of
email
for moderated postings.