Re: [ietf-smtp] broken signatures, was Curious

> This collection of threads actually started with a claim that
> long header field names were causing operational problems. It
When someone makes a claim like that, they need to document it.  Nothing 
in this thread has done anything like documenting the existence of an 
operational problem.  Unless I missed it, but I don't think I did.
Rather, what happened was a claim that then led to lots of /other/ 
people putting quite a bit of energy into evaluation of all sorts of 
information, none of which demonstrated any operational problems.
Or even tried to, IMO.


> I'm not convinced.  I infer that you are not convinced.  From
Things that cause operational problems are described very differently 
than what's been happening here.  They state the problem(s) that are 
caused and then give details about how, when, and where.

>    So, if someone really wants to make the case that the
> language about <optional-field>s in 5322 causes problems without
> some addition specification or restrictions, I think that is,
> sadly, in scope. 
There is a difference between saying "I think bad-thing-x is happening 
and causing problems" from saying "bad-thing-x is causing the following 
problems, in the following ways and with the following systems."
Someone claiming a problem has the burden of documenting that the 
problem is real.
It is not reasonable for them to raise a question and expect other 
people to do the work of proving/disproving.  The latter approach is, 
effectively, a denial of service attack. (There are, of course, 
exceptions, but the framework of legitimate vs. questionable is really 
quite straightforward.)

 I would hope that we could handle it in the
> Applicability Statement that I hope will accompany
> 5321bis/5322bis but that is ultimately up to the WG.
People continue to love ASs, but my impression is that they have no 
field utility.

> And I hope we don't have to fuss with optional header fields at
> all and will conclude that the text in 5322 is adequate without
> even a reference to the registry.   But I don't think we can
> shut off the discussion and prevent those who think there are
> operational problems from making their case until someone is in
> a position to make a consensus call.
In formal terms, that is of course correct.

But people can choose to not respond to postings lacking in-scope 
relevance or substance.
That's why I refrained from posting, but the fact that this thread 
persisted suggested a meta-issue worth broaching early in the wg effort, 
in the possibility it has continuing relevance.  I mean, it's just 
possible that people will have other opportunities to lose focus from 
the actual goals of emailcore.  Shocking, I know, but...

d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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