ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] Email standard revision, was address maximum length

2019-11-25 21:38:33
On Tue, Nov 26, 2019, at 13:45, John C Klensin wrote:
--On Sunday, November 24, 2019 12:35 +0100 Alessandro Vesely
<vesely(_at_)tana(_dot_)it> wrote:

On Sat 23/Nov/2019 13:35:00 +0100 John C Klensin wrote:
there is an effort afoot to get revisions to 5321 and 5322
out there.

Where?

This rather long response is addressed rather more to a future
discussion about a scope statement for a possible WG to update
some mail documents as it is a specific answer to Alessandro.
As a result, he should probably be recognized for opening a can
of worms :-)

I think there's a set of three questions which are raised by this discussion:

1. Should we ever review/revise 5321 and 5322 within the IETF?
2. If yes, should we review/revise them NOW? (for some value of)
3. If yes, where should that revision work be done?

If anybody disagrees with me on this set of questions and ordering, I'd love to 
hear it! I can't think of any other questions or a better ordering, but I may 
well be wrong.

Assuming my questions are sane, let's look at them:

*1.* I'd say there's a very strong argument that we shouldn't leave those two 
documents as the final form "forever". As John pointed out, there are some good 
justifications for revising them at some time, including:
 * citations are still more common for 2821
 * there are various errata which it would be good to address
 * the documents don't necessarily describe actual practice in the real world 
(not necessarily an argument for changing them, but if we don't think the best 
solution is "push people to adopt the precise detail of the standard" then a 
better alternative is publishing the document that we do want to push people to 
follow).
 * (significantly tongue in cheek) It would be way cool to get numbers ending 
with 82X again instead of 32X. Everyone knows 82X.

If you disagree with my assumption that this is enough to justify "YES" to 1, 
then we stop here. Otherwise let's move on.

*2.* If not now, when? Are there any conditions which mean that a time in the 
future would be better for doing this work than now? Some examples might be:
 * experiments in progress with outputs which will inform the new documents
 * expected changes in the userbase which will obsolete work done now
 * excessive short-term workload on the people best suited to work on or review 
these documents, which means they are likely to have more availability in the 
future.
 * (ever so slightly tongue in cheek) a bunch of people are expected to 
retire/die in the near future who would otherwise gum up the works

Unless one of those exists to justify a delay in the work, a YES to 1 implies 
we might as well do it now!

Which brings us to:

* 3. *Where? Clearly this belongs in ART. Clearly this requires a working 
group, this is not AD-Sponsorship level work. I'm sure the ADs will have things 
to say here, but I think it makes sense to spin up a specific working group to 
handle just this piece of work.

Regards,

Bron.

P.S. I tell a lie above, I have thought of another question which belongs 
somewhere in a cloud with (1) and (2), which is "should these two documents be 
revised as a mini-cluster, or is there a scenario in which it makes sense to 
just revise one and leave the other untouched"?


--
 Bron Gondwana, CEO, Fastmail Pty Ltd
 brong(_at_)fastmailteam(_dot_)com

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp