--On Monday, December 12, 2022 12:32 +0000 Alexey Melnikov
<alexey.melnikov@xxxxxxxxx> wrote:
> Hi John,
>
> Replying to one specific issue:
>
> On 11/12/2022 16:14, John C Klensin wrote:
>
>> (3) While "Expires:" has been documented (and standardized) in
>> the IETF only for X.400 gateways ("MIXER") and Netnews, it has
>> been used (at least in the past) for other applications. The
>> fact that certain of us "have never seen" those uses is not a
>> reliable indication that they have never existed, nor even
>> that they are are no longer in use, even in communities that
>> do not participate in the IETF. There are also no guarantees
>> that those other uses have the same semantics as those this
>> document proposes (even if the issues in (1) above are
>> ignored).
>
> Isode has used "Expires:" as defined in this draft for at
> least 6 years, albeit in a small deployment.
Given the connections of Isode leadership to the MIXER work (and
parts of the X.400 work before it), the only surprise there is
"at least 6 years" rather than much longer. It would be even
more surprising if the definition used were different from
either the definition in this draft or the essentially
equivalent MIXER and X.400 ones.
So, without reducing or challenging the importance of that
implementation at all, the cases I'm most concerned about
involve two things:
(1) The X.400 definition, and hence the MIXER one, is a little
vague about the actual meaning of "loss of validity" and any
terms that are used instead of it.
are system. Normally, when we talk about interoperability in
the IETF, we tie ourselves to a particular meaning of the terms
we use. If the real intention of this spec is that one can
specify and send a message with an expiration date with any
possible interpretation or expectation about what terms like
that mean, and implement such a date with a similarly broad
range of interpretations and no clue about which one the sender
intended, I guess I'm ok with that, but it should be explicit.
And, fwiw, in that context 'has used "Expires:" as defined in
this draft' doesn't actually tell me much of anything.
So, what would be really useful would be to either identify
email implementations that use "Expires:" and that are not
ultimately derived from or inspired by the X.400 usage or that
have departed significantly it, perhaps by defining in some very
specific way what X.400, MIXER, and this draft have failed to
define. I've tried to point to some systems that might meet
the second criterion. I'm not aware of any that would meet the
first (i.e., no X.400 heritages at all) but that is no more
proof that the don't exist than what one or several of us "have
not seen".
and...
>> Preferred suggestion: Header field names are not a scarce
>> resource. Use a different keyword, the intentions for which
>> and the associated semantics are clearly spelled out;
>> reference the definitions of the MIXER and Netnews "Expires:"
>> header field; and indicate that the new header field is
>> intended to subsume and replace them.
> My preference would be to keep the existing header field, as
> this will introduce less confusions and avoids the need for
> migration.
An entirely reasonable position, but that leads to my second
concern:
(2) We have an explicit discussion of the tradeoffs between "new
header field", presumably with more explicit definitions and
less handwaving, and "avoiding the need for migration" even if
some small incompatibilities are produced. I am more concerned
that the decision about those tradeoffs be explicit (and
documented in the spec) than ignoring the "new name" possibility
--as has seemed to be the case in messages from the authors so
far-- than which decision is made.
I didn't including "less confusions" in that comment because I
can argue that a new header field with a clear (and single)
definition would create less confusion in the long term than
living with the ambiguity although I can equally argue that
having to choose between header fields with similar meanings
(especially if both appear in the same header collection) is
more confusing.
>> Or, if there really are reasons to preserve "Expires:" in this
>> document despite the risks of possible confusion, at least
>> clearly state those in the document and warn against possible
>> misinterpretations of intent.
>
> That would be fine with me.
See above.
best,
john
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
