On Mon 2019-01-14 18:09:41 -0500, John R Levine wrote: > On Mon, 14 Jan 2019, Daniel Kahn Gillmor wrote: >> On Mon 2019-01-14 16:43:15 -0500, John Levine wrote: >>> To show that you read it, please include the first word in the text >>> on page 50 of RFC 5321 in your reply. >> >> I'm sorry to spoil it for everyone that the word is "The" :P > > Sigh. Nope.
Maybe you're reading a different RFC 5321 than i am. https://tools.ietf.org/html/rfc5321#page-50 begins with: The reply text may be longer than a single line; in these cases the If you'd like to share what you think it is, i'd be happy to learn from you. But i'm telling you my best interpretation of the RFC as i understand it. Anyway … > Right. As far as I can tell, it's there for symmetry with the FROM clause > where the first domain is the HELO/EHLO and the second is the rDNS for the > connecting IP. I don't think I've ever seen the second name used in the > BY clause. yep, it looks like it might even be an accident of some sort of ABNF consolidation. It's a good observation, and seems like a reasonable place to slip in the SNI without needing any extra specifications for now. I do observe that in the presence of a single parenthetical aside between the mandatory part of the BY clause and the next stated clause, it's pretty hard to see how an interpreter can distinguish whether the contents of the parenthetical is a TCP-info (part of the BY clause) or a Comment (not part of the BY clause), particularly if it matches the ABNF for TCP-Info. That makes interpretation potentially ambiguous in the most perverse corner cases. Is this a TCP-info or a comment with a weirdly-formatted timestamp: "(Postfix [19.01.14.23])" Probably fine to interpret it as a a TCP-info since it matches the ABNF, but it's still a little weird that the ambiguity can exist. >> I know that you're frustrated, but please be gentler with people who >> don't have as much in-depth knowledge of the RFCs as you do. > > Wait a minute -- this is the UTA working group of the IETF. The point of > this group is to revise and extend and update and write RFCs. If people > can't be bothered to read the RFCs they're purportedly working on, why are > they here? I didn't ask you to not urge people to read the RFCs. I asked you to be gentler with people. RFCs are written in an, um, peculiar form of English, and ABNF itself is an even more peculiar communication style. Not everyone has the same background in reading and interpreting these things, and even those of us who are native English speakers and who have years of experience reading this particular literary genre can come to disagreements about things like, say, what the first line of page 50 actually says. :P > I checked the syntax in RFCs 5321, 5322, and 8314 before I asked my > question, and other people can too. Sure, and people can look at examples that they have, and people can get stuff wrong too. We want *more* people to understand this stuff and engage with the IETF on how to proceed, let's not drive off the folks who are clearly trying to enagage helpfully. :) Your pointers to the specific references and your explanation of how you expect to address your implementation are both super helpful to the community here. Claiming that you're the only one who reads the RFCs and claiming that RFCs are obviously obviously comprehensible to anyone who tries to read them, not so much. When i commit my next public misinterpretation of an RFC on a mailing list we share (it will happen!), i'm asking you nicely to please point me in the right direction if you know it, with a minimum of eye-rolling and harrumphing. It's scary enough for newcomers to participate in these lists, and we all have made mistakes here. All the best, --dkg
signature.asc
Description: PGP signature
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
