On Sat October 30 2004 16:17, Keith Moore wrote:
a) specify that Archived-At is one of those fields that should be taken
from the encapsulated message header,
Agreed (I think I suggested as much). However, as noted earlier,
existing implementations of message/partial fragmentation and
reassembly will continue to use the existing RFC 2046 rules
(possibly as amended by RFC 2298 for recent implementations).
As might be expected, there are interoperability considerations;
for example a fragmented message prepared with amended
rules, but reassembled by a legacy implementation would lose
all Archived-At fields. And vice versa. [As an aside, that seems
to be an inherent problem with the message/partial rules, as
discussed on ietf-822 in the past. I think it may be possible to
specify fragmentation/reassembly rules that do not have those
problems, but I'm not yet ready to make a detailed proposal.
Which would be orthogonal to the current discussion.]
and perhaps
b) specify that Archived-At should not be used to point to archives of
message/partial
Sounds reasonable, at least as a recommendation (I think
RFC 2119 "MUST NOT" would be too strong).
or
c) specify that Archived-At fields should be removed from any message
that is fragmented
That's possible, but would of course remove any corresponding
functionality. It would call for explanation of who should remove
the field, etc. [As noted above, removal may indeed result as a
side-effect of fragmentation/reassembly rule interaction.]
I don't see that this is a showstopper for archived-at.
Probably not, but as the issue has been identified (i.e. it is a
known technical issue), it should be addressed properly rather
than being swept under the rug, especially if the draft is intended
to be Standards Track ("no known technical omissions").