I read all of Ned's interesting replies on this topic, observed that
they had all been CCed to usenet-format(_at_)clari(_dot_)net, and deleted
them,
intending to deal with them when I dealt with the day's postings to
the usenet-format list (which I have gated to a local newsgroup on my
machine).
Then I go to my local newsgroup and they are not there :-(. Presumably
because, due to anti-spam measures, Ned does not have posting privileges
to the list. Cc to Brad to ask him to fix this, so at least Ned can post
to the list.
I've long since gotten sick and tired of these sorts of draconian anti-spam
measures being applied to lists, especially to IETF lists where the
operational rules forbid it.
As I operate a number of IETF lists myself, which as it happens receive a huge
amount of spam, and I manage to do it in ways that prevent of the spam from
getting to the list, I absolutely reject that things have to be this way.
Unfortunately I have neither the time nor the patience to engage in a
protracted struggle with list managers, in particular a struggle which
previously has never resulted in a satisfactory outcome. So I didn't complain,
and simply deleted the bounce messages.
However, please be aware that development of protocols has to be an open
process, and should someone file an objection/appeal of a protocol developed on
such a list, speaking as an IAB member I for one would have a difficult time
rejecting such an objection out of hand.
I would also hope he would subscribe to it, at least while
this present thread runs. (email to
usenet-format-request(_at_)clari(_dot_)net with
subscribe your-email-address in the body).
Sorry. I already received well over 400 messages a day. I have limited
bandwidth and the USEFOR list is _extremely_ high volume. I have no time
to spare to deal with it.
So could anybody who still has copies let me have them, or better post
them to the list?
BTW, what is ietf-822(_at_)imc(_dot_)org? Some RFC822-email list I presume.
Should
it continue to be included in these exchanges?
ietf-822 was the list where MIME was developed. As such, it is the right
place for discussions of MIME-related issues.
So, dealing with the points raised as best I can remember them, Ned
seems to be suggesting that it is possible to cope with headers with
8bit characters in them within the existing message structure, even
within message/rfc822. But I just do not see how this is possible. So
please can we have an explanation of how it's done, preferably with a
simple example. I agree it would be far better to use a message type
if it can be done, and using an application type was known to be a
second-best kludge when it was put forward.
I already outlined the path forward: First we finish 822bis, so we have a
coherent specification to work from. Then we form a design team to put together
a specification for how 8bit in headers would work. Please note that the notion
that you can simply say it is OK to use 8bit in headers is a dog that does not
hunt. You to have specify where it can be used, what its semantics are, you
have to specify how to downgrade it to 7bit, and you have to give a revised
grammar for the result. Nothing less is likely to pass muster. And while I'm
fairly sure that UTF-8 is the right answer here, there may be substantive
profiling issues with how UTF-8 is used (language tags in particular come to
mind).
Then we'll likely need to define an SMTP extension to negotiate the use of 8bit
headers in mail. I don't know about NNTP. You say that NNTP is 8bit clean, and
who am I to argue, but this leaves the substantive issue of how to handle NNTP
gateways to other environments, to say nothing of client support for UTF-8.
And once all this is done there should be no problem putting 8bit message
headers in message/rfc822 parts.
Ned