From: Russ Allbery (rra@stanford.edu)
Date: Mon Oct 18 1999 - 17:50:00 CDT
I've done a lot of the previous talking on some of these, but just as a
summary I'll throw out my opinions again.
Charles Lindsey <chl@clw.cs.man.ac.uk> writes:
> References:
> -----------
> 1. (Me)
> Trimming SHOULD be done by removing sufficient identifiers starting with
> the second so as to bring the total down to 21. However, software MUST
> be able to handle References headers that contain more than 21 message
> identifiers.
> 2. (Current draft, and the default if we do not agree otherwise)
> Trimming SHOULD be done by removing any incomplete or otherwise broken
> message identifiers, and then sufficient identifiers starting with the
> second so as to bring the total down to 21. However, software MUST be
> able to handle References headers that contain more than 21 message
> identifiers.
There are problems either way; leaving broken message IDs in the header
may cause problems and seems less clean, but that also assumes that
software has a good idea of what is and isn't a broken message ID. I
don't think I have a strong preference one way or the other on this. I do
prefer one of these over saying what identifiers to retain, which seems
unnecessarily verbose.
> Distribution:
> -------------
> Are we agreed to leave negative distributions in, as in:
> Distribution: world, !us
I'm not a big fan, but I can live with them.
> Do we want to remove the convention that ISO 3166 country names are
> distributions without further ado?
My opinion is yes.
> 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.
> Lines:
> ------
> It currently says:
> Software SHOULD NOT use the value of Lines for any purpose other than to
> display an estimate to humans. This header will be deprecated in a
> future version of this standard.
> Do we want to deprecate it more strongly than that, even in this draft?
My opinion is yes.
> 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.
> 2. In order to allow the 'tspecials' characters and UTF-8 characters in
> product-tokens, we allow you to use a quoted-string (RFC 2616 allows
> only ASCII without any tspecials at all). I am happy with that, but it
> could be argued that, since a product-token does not need to be parsed
> or recognised by software, one might go further and allow even more
> unstructured strings to be allowed (but that would be getting even
> further from RFC 2616).
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?
> 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.
> It seems generally agreed that the first part of a multipart gets
> displayed inline, but there is no agreement as regards the subsequent
> ones. The Turnpike people would like them all to be displayed (and would
> even allow you to end one part and start the next within the same line,
> so as to change characters and languages in mid-sentence). No no other
> user agent does anything like that AFAIK, and most show every part after
> the first as an attachment.
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.
> 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.
> If we retain message/news, there is still the matter of the remark about
> using this type when mailing a courtesy copy of a followup. I am
> inclined to remove that remark, and just say that message/news is for
> encapsulating articles for whatever reason, except when the intent is to
> have them (re)injected.
Sounds good to me.
> Replaces: / Supersedes:
> -----------------------
> We discussed this many months ago, and the present text reflects the
> outcome of those discussions. But we have not had many comments about
> them in this round. Is everybody happy?
I don't remember seeing anything that particularly bothered me.
> The only question I have is my choice of the token "usage" as in
> ...; usage=replace
> Anyone want to suggest a better word?
intent?
-- Russ Allbery (rra@stanford.edu) <URL:http://www.eyrie.org/~eagle/>