From: Charles Lindsey (chl@clw.cs.man.ac.uk)
Date: Tue Oct 19 1999 - 04:43:08 CDT
In <ylk8okl1wn.fsf@windlord.stanford.edu> Russ Allbery <rra@stanford.edu> writes:
>Charles Lindsey <chl@clw.cs.man.ac.uk> writes:
>> Approved:
>> ---------
>> Do you want me to say, somewhere, that injectors responsibilities
>> include ensuring that the address in this header must be genuine.
>I think we'd better leave this for a more complete discussion of
>moderation; there are some problems with doing things that way. One that
>comes to mind is that by news.answers convention, FAQ posters put the
>news.answers moderation address in the Approved header after they've
>gotten approval to do so. There's pretty much no way that the local
>injector could check something like that. Similarly, I've given FAQ
>posters permission to crosspost to groups I moderate in the past and add
>my address to their Approved header.
Yes, a good point. However, there is much variation here. The news.answers
moderators do not insist on having "news-answers-request@mit.edu" as the
Approved line, and looking through a sample on that group I find many that
don't (all the ones in news.announce.newusers for a start). Some have both
the news-answers-request and the moderator's own one as well.
Certainly, the most we could insist on would be that one of the items in
the Approved line was verifiable. I agree that we discuss this properly
when we come to the appropriate chapter, but in the meantime it would be
useful to continue examining the possibilities, and perhaps also have
discussions with the news-answers moderators.
>> User-Agent:
>> -----------
>> 1. We do not allow any comment before the first product token. For
>> example, you cannot say
>> User-Agent: (yawn) Forte-Agent (shudder)
>> on the grounds that there is supposed to be a convention that comments
>> refer to the product-token immediately preceding. I could live without
>> this (and leave it to common sense).
>I could too, but on the other hand if we're breaking from RFC 2616 (which
>seems massively underspecified to me; some convention for seperating the
>product name from the version should, at the very least, be given) there
>doesn't seem to be much point in not doing what makes the most sense given
>our specification.
Eh? Both RFC 2616 and our draft make provision for "product/version",
where both "product" and "version" are tokens (or possibly quoted-strings
in our case).
But the more I think about it, the more I would drop that special rule
about an initial comment. It gains little, and goes against the normal
rule of where comments are allowed.
>Nah, I'd say stick with quoted strings; you do want to be able to parse
>the string at least to the degree of separating the product from the
>version number. I can't get to landfield at the moment, but my memory is
>that we do have something for that, correct?
See above.
>> 1. What convention do we establish regarding the default distribution
>> when no Content-Distribution is present?
>Is this in our ballpark? I would have hoped that this was up to [MIME] to
>decide rather than being left for individual applications.
There is a complete void in the Mime specs at this point, so we can fill
it if we want to.
>Gnus does the same thing as Turnpike. Gnus uses multipart messages to
>encode messages that require multiple character sets to represent. There
>was some discussion of this on the Gnus mailing list, and I think the
>consensus was that an informed reading of the standard and some thought
>about what a multipart text/plain message meant indicated that this was
>the right thing to do.
The discussion I just initiated on the ietf-822 list seems to be saying
the same thing, even in its initial reactions. If that opinion is
sustained, then I think our draft could throw some modest weight behind
it.
>> 2. Do we want to remove the message/news type, and encourage people to
>> use message/rfc822 instead. Either way, there are some remarks to be
>> made about the fate of any UTF-8 characters in headers, but these
>> remarks can be made in the context of either message/news or
>> message/rfc822.
>No particular opinion here. I think this may be best left up to the IETF
>folks to decide, since I think the main issue revolves around UTF-8.
Actually, I don't think this is a UTF-8 issue. message/news and
message/rfc822 are essentially identical as currently defined, and both
may have modest problems with UTF-8 (which our draft does/should warn
about) which will not be resolved totally until the mail people get their
act together, which eventually they will.
-- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Email: chl@clw.cs.man.ac.uk Web: http://www.cs.man.ac.uk/~chl Voice/Fax: +44 161 437 4506 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