From: Charles Lindsey (chl@clerew.man.ac.uk)
Date: Sat Apr 26 2003 - 14:13:34 CDT
On Fri, 25 Apr 2003 17:49:51 -0400
Bruce Lilly <blilly@erols.com> said...
>
> Charles Lindsey wrote:
> > On Mon, 21 Apr 2003 13:28:24 -0400
> > Bruce Lilly <blilly@erols.com> said...
>
> > 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.
OK. The whole business of line length limits will have to get split
between the standards document and the netkeeping document, so I will
bear that in mind (I am looking at that split at the moment, as already
mentioned in another thread).
> >>>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.
> >>
> 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?
It was taken from son-of-1036. Perhaps Henry should speak up, but I
think it is related to that obligatory SP after the ":". If some agent
somewhere tries to remove trailing whitespace (not allowed, but that
will not stop it from happening), then that SP may get removed as well,
and something else will break further down the line.
>
> >>>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.
> >
> It was in RFC 733, which predates Usenet. It's also in 822 which 1036
> defers to on most matters.
Are you sure? What was the date of RFC 733? Usenet is certainly quite a
bit older than the Internet.
>
> What's the big deal anyway?
> Keywords: foo
> Keywords: bar
> should be considered semantically equivalent to
> Keywords: foo, bar
Does anybody know why multiple Keywords headers were allowed in Mail? It
does not seem to have any practical use. Has anyone ever seen it happen?
>
>
> 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.
This was discussed quite thoroughly in the early days of Usefor. There
is some software around, apparently, which looks at the "Re: " for
various purposes, and anything which generates "Sv: " will break that.
>
> > 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.
There IS a specific list of the fields UNaffected. The whole point
was that this was intended to apply to all Netnews headers, including
extension headers, unless there is a special reason not to.
>
>
> 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...
>
I am assuming that, having postponed the I18N stuff, the rest of the
proposals stand, and that what we are doing now is basically to create
final texts (split into various separate documents and tidied up in
various ways). I do not want to be creating those tidied texts at the
same time as we are putting features in or taking them out (except
for very minor points and, of course, bugs). We had an internal last
call a year ago, and it was only the UTF-8 stuff that casued the real
disagreements. But perhaps the chairs should institute another internal
last call on _features_ to clarify the matter.
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@clerew.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