From: Andrew Gierth (email@example.com)
Date: Thu May 09 2002 - 06:15:09 CDT
>>>>> "Erland" == Erland Sommarskog <firstname.lastname@example.org> writes:
>> untrue - the draft even goes so far as to use "SHOULD" for folding
>> the Path header
Erland> Since folding of Path apparently is in 1036, Path is not
Erland> covered by "attempts to introduce changes". If we were to
Erland> revert completely and outlaw folding of Path, we would have
Erland> to make a note with regards to RFC 1036, wouldn't we?
"RFC 1036 permitted folding in the Path header, but no implementation
ever did so, and many existing implementations do not handle folded
Path headers properly, accordingly the feature is removed."
This is no different from any other attempt to remove a feature which
is neither used nor required. We remove several features from 1036,
e.g. sendsys, version, or timezone names in Date headers.
Erland> As for folding Newsgroups, I would welcoming folding of it
Erland> from a user perspective. I moderated the announce group for
Erland> the se. hierarchy, and articles are often widely
Erland> cross-posted. Being permitted to fold Newsgroups or use space
Erland> would faciliate my work. (I assemble the articles in Emacs,
Erland> and post directly with inews.)
that's a trivial tool issue. If you want to prepare articles in some
form other than the standard one, then do so and perform the
I can think of several features which might make life easier for people
who want to hand-compose articles. None of them would justify having to
make changes all through the transit system.
Erland> Now, tell me, Andrew. If we wanted to make this improvement,
Erland> what would be the best path to take? First approach all
Erland> newsserver authors and have them change their software, and
Erland> keep an eye on things coming out on the market at the same
Erland> time. And, one day when we know that all currect software OK,
Erland> we revise the standard. Call me stupid and nave, but it
Erland> appears to be a more effective way of introducing it in an
Erland> RFC with a initial SHOULD NOT generate.
That was the son-of-1036 approach, which generally failed. Standards
don't change the world. _Implementations_ are what count. So yes, if
there's any feature that you want, you _SHOULD_ be talking to the
implementors about it, NOW, rather than assuming that they will
co-operate later just because you wrote something in the standard.
(Alternatively, you can publish some actual patches and see whether
people take them up.)
Instead, what do we see? The people on this group with the most
experience of actual existing implementations are the people who are
most ignored. Getting unimplementable features removed from the draft
has been like pulling teeth.
>> Reviewing the list traffic at the time suggests that many of the
>> people responding supported retaining the policy issues only in
>> the interests of producing a completed draft, on the assumption
>> that _any_ document was better than nothing.
Erland> Yes, count me in on that one.
Erland> And I can give a specific argument. For me this entire
Erland> standard stands and falls with one thing: UTF-8 in newsgroup
Erland> names. Take it out, and I cannot find much justification for
I'm inclined to agree. But I'm _not_ prepared to agree that UTF-8
group names (which _do_ still need some real work, especially when it
comes to sorting out the moderation mechanisms) are important enough
in themselves to justify a "standard" which is full of arbitrary and
ridiculous policy baggage and gratuitous incompatibilities.
>> I disagree; I think that the current draft is sufficiently bad
>> that it would be better in the long term for it to die, and for
>> those changes that are actually necessary to continue happening as
>> they have done for the past 15 years since RFC 1036, than for it
>> to be published as an RFC in its current form.
Erland> OK, how we get UTF-8 in newsgroup names without an RFC? (It
Erland> has not to be UTF-8, as long it permits groups to be called
Erland> se.test.rksmrgs, but it appears that UTF-8 is the most viable
Erland> solution in the long run.)
the dk.test.whateveritis group is out there now and has been for a
while. The next step should be to create a moderated one and fix any
problems _that_ causes.
But that doesn't have to hold up work on the standard. Adding UTF-8
group names doesn't seem to have broken anything in any way that
affects people who don't actually use them, so any detail changes that
turn out to be necessary could be dealt with in the transition from
proposed standard to draft standard. The problem is with the rest of