Re: Internal LAST CALL

New Message Reply About this list Date view Thread view Subject view Author view

From: Charles Lindsey (chl@clw.cs.man.ac.uk)
Date: Wed May 08 2002 - 08:37:21 CDT


In <yloffr7axa.fsf@windlord.stanford.edu> Russ Allbery <rra@stanford.edu> writes:

>MIME-style parameters are introduced wholesale in existing headers rather
>than just in newly added headers, and there is, so far as I know, no
>operational experience with this.

Nor would there be any means of gaining such operational experience in
advance of this standard. There are "SHOULD NOT generate"s in all the right
places.

>There's a whole bunch of pointless pseudo-standardization of the structure
>of the body of messages that would save several pages if it were ripped
>out in its entirety or moved into an informational RFC.

Moving stuff into another RFC does not save pages in total. It is all
codification of existing practice.

>UTF-8 newsgroup names break moderated groups as nigh-universally
>implemented today.

Yes, that problem is noted, but it is for the mail people to solve (see
current threads in ietf-822, where they at least seem to agree that it
needs solving).

>There is very little operational experience with the new Path stuff on the
>broader Usenet.

Again, there is no way to gain such operational experience in advance of
the standard. We have checked what we can, and it seems that nothing
serious will break.

>The description of the Distribution header bears little resemblence to the
>reality of implementations and it's highly unlikely that implementations
>are going to change to match.

We took a deliberate decision to add features which might make the
Distribution header of some use again. The alternative would have been to
abandon it, because it is useless as it stands.

>There's no operational experience with Injector-Info, and it doesn't serve
>quite the same purpose as NNTP-Posting-Host is being used for today. It's
>not going to *hurt* anything technically, but there's also no evidence to
>indicate that it will actually clean anything up rather than just becoming
>Yet Another Trace Header that some sites have and some sites don't. It's
>excessively complex, hard to parse, and doesn't address many of the actual
>uses of trace headers.

Actually, I have seen an Injector-Info, correctly used, in the wild.

>There are random limitations and side comments about MIME rather than just
>adopting MIME, mostly serving to just confuse the issue or to make various
>policy points that aren't relevant to the underlying *protocol*. Some of
>this may be good material for a best practices document.

We took out most of the conflicts with existing MIME usage, largely at
your instigation. However, MIME was designed specifically for use in mail,
so it could hardly be expected to be a perfect fit for news. One hopes
that the next round of MIME standards will take both media into account.

>application/news-transmission isn't going to win us any friends among most
>moderators.

For non-MIME-aware reading agents, it will be indistinguishable from
present practice. You yourself have agreed that encapsulation of articles
sent to moderators is a desirable improvement.

>There is no operational experience with mvgroup apart from an experiment
>with C News and I'm not aware of a widely used server that's deployed
>support for this.

As it now stands, defining mvgroup as an alias for newgroup will give a
minimally compliant implementation. Obviously, deployment (and use) in
advance of this standard could not happen.

>The changes in the body syntax of newgroup and the MIME type of
>checkgroups are not existing practice, are not currently implemented, and
>are unlikely to be implemented any time soon in many parts of Usenet.
>Again, no operational experience with whether this will break anything.

It is all designed so that non-MIME-aware servers (and that is probably
all of them at the present time) will not notice the difference.

>The initial article idea has, again, never been implemented and we have no
>idea how it will work in practice.

Trus, but ignoring the feature will cause no harm. It will still achieve
as much as the present practice of including charters and the like in
newgroup messages.

>No operational experience with the new parameters to the checkgroups
>message.

I had the impression that there was a little use of them in practice. But
they do not seem like rocket science, and ignoring them falls back to
something safe.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: chl@clw.cs.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5


New Message Reply About this list Date view Thread view Subject view Author view


This archive was generated by hypermail 2b29.