From: Charles Lindsey (chl@clw.cs.man.ac.uk)
Date: Wed Oct 27 1999 - 10:34:34 CDT
In <199910181537.QAA15990@clw.cs.man.ac.uk> Charles Lindsey <chl@clw.cs.man.ac.uk> writes:
>We seem to have gone quiet. Here are the remaining issues in Section 6
>for which I still need guidance.
I have now considered all the replies in this thread, and have taken
action as follows:
>References:
>-----------
>The question of how we truncate to 21 entries still remains. Here are three
>possible texts:
>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.
>3. (Clive)
>Trimming SHOULD be done by removing any incomplete or otherwise broken
>message identifiers, and then sufficient identifiers so as to bring the
>total down to 21. Agents SHOULD keep the first 1 and last 9 identifiers,
>and in the absence of any obvious candidates MAY wish to remove starting
>from the second identifier. However, software MUST be able to handle
>References headers that contain more than 21 message identifiers.
Clive did not push his text, and all other respondents preferred #1 or #2.
There was a slight preference expressed for #1, so #1 it is.
>Distribution:
>-------------
>Are we agreed to leave negative distributions in, as in:
> Distribution: world, !us
No change made here.
>If so, then I will do something about making
> Distribution: !us
>work (but, if not, then no point wasting my effort).
Done.
>Do we want to remove the convention that ISO 3166 country names are
>distributions without further ado? We seem agreed that most practical
>uses for this header will be in closing leaks, and special tricks for
>use by cancellers and NOCEM writers. I would still encourage 3-letter
>distributions for non-country names, though.
Done.
>Approved:
>---------
>Do you want me to say, somewhere, that injectors responsibilities
>include ensuring that the address in this header must be genuine. Or
>should we leave that until we come to responsibilities of injectors in
>a later chapter, or until we deal with other related issues such as
>authentication?
No action yet. Revisit it when we come to Moderation.
>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?
Done, due to overwhelming demand!
>User-Agent:
>-----------
>It seems not realistic to ensure absolute compatibility with RFC 2616, for
>reasons already stated. But in two respects we do go beyond RFC 2616:
>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 have made this change.
>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). Typically, in Mime usage, tokens are used where
>software has to recognise them, and values (which allow quoted-strings)
>are used for parameters, as in "filename='foo<>bar'".
No change made here.
>It seems agreed that this section is too verbose, but no-one has
>accepted my invitation to prune it. Do you want me to try to do this?
I have done a severe pruning. See diffs in a separate message.
>Mime headers:
>-------------
>Any comments on this section? We have not discussed it particularly, and
>the only two issues raised so far are the following:
>1. What convention do we establish regarding the default distribution
>when no Content-Distribution is present? 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.
>The present draft sits on the fence and says that both these conventions
>are acceptable, which does not really answer the question at all.
>I have started a thread on the ietf-822 list, to see what the email
>people think about this one.
After the discussion in the ietf-822 list, it seemed that people expected
text types to appear inline by default, but there was no general agreement
as to whether adjacent text parts should be combined as one, Turnpike style
(it transpired several other agents did this as well as Turnpike), or
whether there should be some indication that more than one part was
involved. It seemed to be agreed that usage of the Turnpike method for
changing charset and/or language in mid-line had never been part of the
original intention, but it clearly did not actually breach the standards.
So I have now adopted the following text, being the minimum that would
express the above:
"Reading agents SHOULD honour any Content-Disposition header that is
provided (in particular, they SHOULD display any part of a multipart for
which the disposition is "inline", possibly distinguished from adjacent
parts by some suitable separator). In the absence of such a header, the
body of an article or any part of a multipart with Content-Type "text"
SHOULD be displayed inline. Followup agents which quote parts of a
precursor (see 4.x) SHOULD initially include all parts of the precursor
that were displayed inline, as if they were a single part."
Having got that out of the way, we now need to return to the bit in
Section 4 which deals with signatures in followups, and which was the
start of this whole discussion. Currently, our text says:
"A "personal signature" is a short closing text automatically
added to the end of articles by posting agents, identifying the
poster and giving his network addresses, etc. If a poster or
posting agent does append such a signature to an article, it
MUST be preceded with a delimiter line containing (only) two
hyphens (ASCII 45) followed by one SP (ASCII 32). The
signature is considered to extend from the last occurrence of
that delimiter up to the end of the article (or up to the end
of the part in the case of a multipart Mime body). Followup
agents, when incorporating quoted text from a precursor, SHOULD
NOT include the signature in the quotation. Posting agents
SHOULD discourage (at least with a warning) signatures of
excessive length (4 lines is a commonly accepted limit).
NOTE: It is undesirable to have more than one personal signature
in an article body (even though the rule above admits the
possibility by recognising only the last one). If, for some
reason, a second signature is considered necessary, it MAY be
preceded by a different delimiter (e.g. "--- ").
[That is Clive's suggestion. Not to be included without further support.]"
Does anyone now want to change that text in light of the fact that we now
expect all multiparts to appear inline? Note that Clive's "--- "
suggestion will not be retained unless someone else supports it (so now is
your chance :-) ).
>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.
Message/news now obsoleted. New discussion of message/rfc822
(incorporating some of the same text) inserted at the proper place.
>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.
Done, in the new message/rfc822 text.
>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?
>The only question I have is my choice of the token "usage" as in
> ...; usage=replace
>Anyone want to suggest a better word?
Russ suggested "intent", but it does not seem really better. Note that I
discovered that my proposal for optional parameters "moderate", "inject"
or "relay" did not conform to the Mime standards, so they now also have a
"usage=" stuck in front of them.
>While you are looking at these headers, you should be looking at Xref: also.
Control:
--------
I raised this in another thread. I have now made the <verb> in a control
message be a token, and I have used CFWS rather than FWS (a token has a
built-in CFWS anyway, so there was not much choice left).
I think this now completes our pass through Section 6. See separate post
for current texts and the start of Section 7.
-- 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