Ted, Personal opinion/ comment: I have felt for many years, and said so a few times, that almost any time a Standards Track specification says "SHOULD" or "SHOULD NOT", there should be such a discussion or explanation. The idea has never gotten any traction and is certainly not general practice. So, for this case, I will do whatever the WG or the community tells me to do. However, the following reads to me as if you are stating the below as a principle. If so, why this provision be required in this document and not the huge number of other documents that state a SHOULD without identifying the exact reasoning one might choose to do otherwise and/or where the consequences of not following the SHOULD are not described. john --On Thursday, October 17, 2024 09:32 +0200 Ted Lemon <mellon@xxxxxxxxx> wrote: > Regarding should not versus must not, I'm not arguing for either > position—just saying that if it's should not you should at > least briefly discuss why an implementation might do this. If > it's for backwards compatibility, and no other reason, that's > worth saying. > > Op do 17 okt 2024 om 08:20 schreef Viktor Dukhovni > <ietf-dane@xxxxxxxxxxxx> > >> On Thu, Oct 17, 2024 at 12:37:16AM -0400, John C Klensin wrote: >> >> > > Non-DNS question: why is the "SHOULD NOT" in paragraph 2 of >> > > 4.1.1.1 not a MUST NOT? What is the exception? >> > >> > I'll like to hear from others in the WG, but there was a certain >> > reluctance to invalidate (i.e., render completely non-conforming) >> > existing conforming implementations without clear evidence of >> > harm. There is no harm here if servers accept it (rather than >> > treating it as an error), even if they then ignore it, which is >> > what the first part of the sentence essentially says. At the >> > other extreme, SMTP servers are basically allowed to decline to >> > accept a message for any reason(s) they find appropriate, so why >> > should this be the exception? I don't have any idea how many >> > SMTP clients do send that information or whether people who >> > think market size is important would consider any such client >> > worth considering. >> >> MUST NOT (client sending) sounds right to me. To the extent that >> Postfix tolerates this, the entire construct "[literal] ..." ends >> up as the HELO name, including the trailing junk. But this would >> typically fail the widely used "reject_invalid_hostname" >> restriction. >> >> > ehlo [192.0.2.1] foo bar >> < 250-... >> < ... >> mail from:<ietf-dane@xxxxxxxxxxxx> >> 250 2.1.0 Ok >> rcpt to:<ietf-dane@xxxxxxxxxxxx> >> 501 5.5.2 <[192.0.2.1]?foo?bar>: Helo command rejected: >> invalid ip address >> >> -- >> Viktor. >> >> -- >> last-call mailing list -- last-call@xxxxxxxx >> To unsubscribe send an email to last-call-leave@xxxxxxxx >> -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
