From: Bruce Lilly (blilly@erols.com)
Date: Fri Apr 25 2003 - 16:49:51 CDT
Charles Lindsey wrote:
> On Mon, 21 Apr 2003 13:28:24 -0400
> Bruce Lilly <blilly@erols.com> said...
>>MIME requires that any header line containing an encoded-word be no longer
>>than 76 octets.
Incidentally, it also applies to encoded (quoted-printable or base64)
body text.
> Yes, but agents must not use that as an excuse to truncate lines that
> are shorter. That requirement is aimed mainly at transports (which are
> not going to look inside encoded-words anyway).
Fine, but posting agents, gateways, etc. shouldn't generate them. Now
that's clear from RFC 2045 and 2047, but it's probably worth reiterating.
Without emphasizing the point, some software author will think that he
can blithely quote text in quoted-printable bodies simply by prepending
something, regardless of how long that makes the lines, or that he can stuff
a "Re: " in the subject without considering whether it has any encoded-words,
and if so, what its length is.
>>>2.3 The content of the first line of a header MUST NOT consist of WSP only
>>> (though such SHOULD be accepted). Observe that continuation lines
>>> of headers also MUST NOT consist of WSP only, as in RFC 2822.
>>
>>The first part of that may be a problem (see above and below re.
>>encoded-words -- it may be necessary to fold).
>
>
> But I don't see why it would be required to fold in such a way that
> there was nothing on the first line - Dirk has explained how it can
> always be folded in some suitable way.
>
> Note that responsibility for enforcing this restriction lies with
> posting agents. They MUST NOT generate them. If a subsequent agent sees
> a violation, it is quite entitled to reject the article (though we do
> say that it SHOULD accept it and pass it on).
Bear in mind that there is no such restriction in either RFC 822 or
2822, that there are such things as mail-to-news gateways and combined
UAs.
Is the restriction still relevant to current news software, or is it
a vestige of ancient software which is no longer used?
>>>2.7 There must not be more than one header with a given header-name,
>>> except where explicitly sanctioned by the appropriate standard. In
>>> particular, there MUST NOT be more than one Keywords-header.
>>
>>But multiple Keywords fields are "explicitly sanctioned by" RFC 2822.
>
>
> Yes, that was a deliberate restriction wrt RFC 2822 (and it was a stupid
> provision in RFC 2822). If keywords are useful for anything, it is for
> indexing articles against them, and that gets just too complicated if
> more than one Keywords header has to be looked at.
>
> RFC 1036 is, as usual, a little vague on the matter, but it does seem
> to imply that this header should occur only once. That is certainly
> the case in son-of-1036. Does anyone know whether Keywords was first
> invented as a News header, or as an Email header?
It was in RFC 733, which predates Usenet. It's also in 822 which 1036
defers to on most matters.
What's the big deal anyway?
Keywords: foo
Keywords: bar
should be considered semantically equivalent to
Keywords: foo, bar
>>I think we should avoid the Subject hacks entirely. Subject is supposed
>>to be an unstructured field. Once one starts saying things like (in some
>>circumstances) the field body MUST begin with "Re: " and/or it MUST NOT
>>begin with "Re: Re: ", it's no longer unstructured. Ditto for "cmsg".
>
>
> I think it is important that followup-agents should process Re: as we
> have specified. However, some of the other stuff in that section might
> be hived off into the #3 document. But remember that the purpose of my
> memo was to document the _present_ state of our draft.
Note that there are issues, such as alluded to above w.r.t. encoded-words.
A followup is always supposed to have a References field and may have
In-Reply-To; in either case sticking "Re: " in the subject conveys no
additional information. Avoiding Subject hacks avoids the "Sv: " problem,
the issues with encoded-words, etc. and leaves Subject as unstructured.
So we probably should have more discussion before finalizing the documents.
>>>3. Rules specific to Netnews headers.
>>>-------------------------------------
>>>
>>>3.1 All headers have MIME-style extension-parameters, with x-attributes
>>> or to be defined in future standards. Some have explicit parameters
>>> defined in this standard. However, this does not apply to headers
>>> which are taken from RFC 2822 or other mail standards, nor to the
>>> Mail-Copies-To, Complaints-to and Supersedes-header defined in this
>>> standard. Nevertheless, such parameters SHOULD be recognized (and
>>> ignored) in all headers.
>>
>>[...]
>> > 3.3.1 MIME-style parameters in headers defined prior to this standard.
>>
>>No, we've had this discussion before. One cannot have parameters with *any*
>>unstructured field (e.g. Organization), and there may well be other cases
>>where the syntax is incompatible. "MIME-style parameters" only make sense
>>for MIME and MIME extension fields; they are currently only used with
>>Content-Type (a MIME field) and Content-Disposition (a MIME extension field).
>>Moreover, as header fields defined elsewhere which do not permit such
>>parameters (e.g. Date) are never generated with such parameters, it is
>>unreasonable to require every agent to be able to accept them. It is
>>impossible for any agent to do so for any unstructured field.
>
>
> Yes, I should have said this applied only to structured headers, and I
> have amended my copy of the text accordingly. But there are no other
> incompatibilities because, as I said, it only applies to headers defined
> for Netnews (and there are exceptions even there). And they are all
> SHOULD NOT generate (yet) for existing headers, so no existing user
> agent should have a problem.
In the interest of clarity, there should be a specific list of the
fields affected. IIRC, there was a syntax issue with Xref last time
we discussed this.
> But it is a useful feature to have for future expansibility, and I
> hope it might be taken up by the Mail people one day (but would, of
> course, take a long time to phase in). Which is why we say they SHOULD
> be accepted in all headers.
Still waiting for guidance from the Chairs regarding the extent to which
we're putting in WIBNIs [*] vs. updating 1036.
* for those unfamiliar with the acronym, it comes from Wouldn't It Be Nice If...