From: Charles Lindsey (chl@clw.cs.man.ac.uk)
Date: Mon Oct 18 1999 - 10:37:18 CDT
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.
Distribution:
-------------
Are we agreed to leave negative distributions in, as in:
Distribution: world, !us
If so, then I will do something about making
Distribution: !us
work (but, if not, then no point wasting my effort).
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.
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?
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?
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).
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'".
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?
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.
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.
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.
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?
While you are looking at these headers, you should be looking at Xref: also.
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