Re: References with multiple precursors (was Attempts at establishing harmful conventions)
Charles Lindsey <chl <at> clerew.man.ac.uk>
2005-01-13 10:47:59 GMT
In <200501120909.05983.blilly <at> erols.com> Bruce Lilly <blilly <at> erols.com> writes:
>On Tue January 11 2005 06:46, Charles Lindsey wrote:
>> So here is a suggestion to get around the problem in a way that will
>> probaby allow existing MUAs to do a reasonable job:
>>
>> Simply allow there to be multiple occurrences of the References header in
>> each message - one for each path from the root to the tip in question.
>No. Expressly forbidden by RFC 2822 section 3.6.2, which specifies
>a maximum of one References field per header.
Yawn!
Has it not occurred to you that what I am suggesting would require an
update of RFC 2822, and of several other documents as well. The whole
purpose of this discussion list is to examine suggested enhancements to
the mail protocols to see whether they are worth pursuing. So it is hardly
sensible to say "you can't consider that change to the protocols because
it would change the protocols".
>
>> Then an updated MUA can look at them all, and has full information
>> available to give the best possible presentation. Meanwhile, an unupdated
>> MUA will probably just take the first, or the last, or a randomly chosen
>> one, and will at least produce a plausible thread.
>That is not backwards compatible. We don't foist illegal content
>(in this case multiple References fields) on widely deployed
>implementations and shrug off the incompatibility with an off-hand
>remark hypothesizing that those implementations will "probably"
>cope in some way.
No, it is not necessarily backwards incompatible, for reasons which I
tried to explain, but which you refuse even to listen to.
It may or may not be the case that existing implementations would break in
disastrous ways if more than one References header was found in a message.
I rather expect they would not, for the simple reason that implementors
would have had to go out of their way to cause such nasties, and
implementors are not noted for doing unnecessary work.
It is indeed the case that no present MUA would generate such a thing, and
might even thwart a user who tried to create it manually, but that is not
the point.
Would any transport fail to deliver it? I doubt it, because I doubt any
transport even bothers to look at the References header. Would any storage
agent fail to store it? I doubt it, because no-one would want a storage
agent so illiberal as to drop malformed messages on the floor (there are
too many malformed messages around for that). It might truncate one of the
'superfluous' headers, but that is not a cause of serious harm.
Would any MUA fail to display the message altogether? No, for the same
reason. Would an MUA fail to display it in a sensible place in a thread?
Yes, that is indeed the problem that might arise. But my guess is that it
would either fail to include the message in any thread at all, or it would
thread it based upon examination of one of the References headers only,
and my reason for supposing that is that I cannot imagine any way of
writing an agent that was expecting to thread based on examination of one
header that would have any effect other than one of those. But the only
way to find out would be to try it on various existing agents, and see.
Yes, the behaviour of such an agent wouold be sub-optimal, but if you
introduce new functionality into a protocol, then you expect sub-optimal
behaviour from agents that have not been upgraded. The same would be true
if you introduced some brand new header to achieve the new functionality,
but that would not amount to backwards incompatibility. There is no gain
without pain.
Anyway, I shall now try to post messages with multiple Reference headers
to this list, so that we can gauge the extent of any possible problems.
Would anyone who completely fails to see them please report here.
Otherwise, please reply to them.
>
>> And it is not actually necessary for the whole of each of the various
>> paths to appear in the various References headers. Just the segment that
>> differs from the others should suffice, though careful thought would have
>> to be given to defining exactly what the rule should be.
>Having failed to give careful thought, you still claim that deployed
>MUAs "will at least produce a plausible thread". Incredible.
>You also failed to take note of the summary of conclusions of the
>earlier discussion; your scheme, in addition to failing to be
>backwards compatible:
>a. ignores that "expecting UAs to coordinate updates to multiple fields
> is probably over-optimistic"; you fail to even mention how the
> multiple References fields which you propose would be updated when
> such a message is responded to.
I am making a suggestion for a method that may be worth looking at further,
and you complain that I have not described every last nuance of a new
protocol. It I had described a whole new protocol at that level, you would
have complained that it was premature to describe the gory details when
the general principle had not been established.
>b. ignores the fact that "several existing UAs botch References and
> In-Reply-To fields, destroying their utility"; illegally adding
> more instances of the field can only exacerbate that problem.
So you are saying that the current existence of broken implementations
should be a bar to all future protocol development?
>c. does not address repetition of message-ids and the bulk associated
> with such repetition; indeed, it involves such repetition
Any solution will involve additional bulk (because there is additional
information to be conveyed). Exactly how much bulk is one of those gory
details which would have to be sorted out if this idea became a serious
endeavour.
>d. ignores the conclusion that "rather than overload additional
> semantics on the References field, a new field or set of fields
> should be developed"
No, the previous discussion reached no such conclusion. Indeed it reached
no consensus at all, except that there were difficulties with all methods
proposed up to that time. There may well be difficulties with what I now
suggest, but progress will never be made unless people are prepared to
evaluate such difficulties to see whether they are outweighed by the
advantages to be gained.
--
--
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 <at> 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
RSS Feed