From: Paul Overell (paulo@turnpike.com)
Date: Tue Oct 19 1999 - 03:57:07 CDT
In article <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.
>
>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.
>
I vote for 1. Advising on what to do with broken IDs seems to me to be
a dangerous precedent. There are so many ways that an article can fail
to conform to the RFC, are we to start advising on these as well?
>
>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?
Content-Disposition shirley? :)
> 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
Not quite, in the absence of a CD: we inline or not according to
Turnpike's capabilities; preferring to inline if possible.
> (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).
This is just following the MIME spec.
> No no other user agent does anything like
>that AFAIK, and most show every part after the first as an attachment.
>
Other followups to this both here and in ieft-822 show that Turnpike is
not alone on this.
>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.
>
>2. Do we want to remove the message/news type, and encourage people
>to use message/rfc822 instead.
Yes. We implemented message/news but found it just didn't interwork -
it gets (correctly) interpreted as application/octet-stream by clients
that don't recognize message/news. We didn't find any other client that
supported it. We have now abandoned it in favour of message/rfc822.
> 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.
Until 8 bit headers are permitted in mail we must specify that an
article within a message/rfc822 MUST have any 8 bit headers recast using
rfc2047. As rfc2047 can only be applied in some specific circumstances
we need to extend it so that it can be used in the Newsgroups: and
Followup-to: headers.
>
>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.
>
Lose message/news
Regards
-- Paul Overell T U R N P I K E Ltd