But it is unreasonable to say that all other internet developments (news
in this case) have to wait until 822bis is completed, and then some new
design team is formed, before they can proceed. This is a problem we
have to solve _now_.
So what you're saying is that the matter is urgent, and its urgency
justifies ignoring dependencies on other work.
I'm sorry, but this just doesn't wash. For one thing, I fail to see the urgency
-- the format for news was last updated well over a decade ago, if memory
serves. 822bis is nearly done and should be out in another month or two. I fail
to see how any sense of urgency could exist that warrants this kind of haste
after a decade of inactivity.
But even if your sense of urgency was justifiable, it still wouldn't wash. The
need for IPP is urgent. The need for security in mail protocols is urgent. And
various other needs in the IETF are urgent. But protocols, including these, are
routinely delayed, sometimes for _years_, because of such dependencies. Heck,
the cumulative delays to MIME because of possible dependencies in other areas
probably cost us a year if not more.
Indeed, I once devised a corrollary to one of Brook's laws, which says:
Adding a sense of urgency to a protocol specification effort usually
slows the effort down rather than speeding it up.
I think you would do well to heed it, because it definitely seems to apply to
USEFOR.
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).
Not so. Within the news environment, all those questions have been
addressed, and downgrading to 7bit is not needed. Gatewaying may get a
bit complicated, but application/news-transmission (which is aimed at
machines rather than humans) gets over some of the problems. Which just
leaves the matter of a human friendly way to transmit news across email
and have is restorable to exactly the same thing at the far end.
Your implicit assumption here is that you'll be allowed to move forward with a
specification that doesn't give detailed, specific, and up to date syntax rules
and without downgrading rules. Now, I'm not in a position to say that you
cannot do this. But I'll tell you right now that I'll be one of the people
reviewing your documents when they make it to IETF last call, and I guarantee
that I will object if these matters aren't covered. I suspect many others will
as well.
And then it will be up to the IESG. I'm not on the IESG, and even if I was I
would be only one vote, but I wouldn't wager much on the chances of getting
this sort of thing through.
We had hoped to use message/something for this, and your earlier
message seemed to suggest that it could be done within the existing
constraints, but it seems not to be so.
Again, I said that I see no problem with using message/rfc822 for this, and as
yet the only objection you've managed to raise is that such usage cannot be
accomplished on your timeline. If you have a technical reason why this cannot
be done I'd like to hear it.
So for the moment we have proposed
application/news-message - not that we like it very much.
Now, this happens to be an area where I, as type reviewer, have an opinion that
carries weight. And in my capacity as type reviewer I'm telling you now that I
will object to the registration of this type. And that, I believe, pushes the
matter before the IESG and IAB. And that is likely to take time -- lots of it.
Please understand that I'm not being obstructive about this just for the heck
of it. I sincerely believe that this is a dreadful idea, one that will cause a
huge amount of pain to the installed base, and one which should not be allowed
to move forward. But one of the side effects of this will almost certainly
be to make use of 822bis possible. And I cannot say I'm unhappy about
that.
I suppose something like the following might be possible:
Content-Transfer-Encoding: 8bit
Content-Type: message/news; boundary="foofoo" (or should it be
multipart/news?)
Other-Email-Headers:
This is an encapsulated news article.
--foofoo
Content-Transfer-Encoding: quoted-printable (1111)
Content-Type: application/news-headers; charset=utf-8 (1111)
(or text/news-headers?)
Newsgroups: various.groups.in.some.greek.hierarchy.using.utf-8.characters
Message-ID: <12345(_at_)foo(_dot_)com> (message-ids are still strict ascii)
Path: here!there!everywhere
Subject: Some Greek text, no doubt
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=iso-8859-6 (or whatever the Greek iso code
is)
Other-News-Headers:
--foofoo
Content-Transfer-Encoding: base64 (2222)
Content-Type: text/plain; charset=iso-8859-6 (2222)
The body of the article, written in greek using iso-8859-6 (whatever).
--foofoo--
An interesting idea, and certainly one that avoids obvious pitfalls. But it is
also unspeakably ugly. And an argument can certainly be makde that
application/news-headers should be a subtype of message.
But even supposing we moved forward with this, the question becomes: Can you
get consensus around this idea faster than 822bis can complete and the job can
be done right?
Then we'll likely need to define an SMTP extension to negotiate
the use of 8bit headers in mail.
There already is such an extension (8BITMIME) but it is only a SHOULD,
not a MUST ;-( .
As a coauthor of 8bitMIME, I am well aware of its existance. However, it
doesn't accomodate 8bit headers.
And as a practical matter any such scheme can never be anything but a SHOULD.
And this is why you cannot avoid the downgrade issue, much as you may like to.
I'll even make you an offer: Do the 8bit in headers job right and I'll write
the 8bitheader SMTP extension document to facilitate getting this done
faster.
And HTTP gatewaying probably needs to be considered as well.
Ned