SM wrote:
As this draft is being considered as a Proposed Standard, will it be
authoritative instead of RFC 5821/5322?
This presumes that there are different semantics or syntax offered by them.
What inconsistencies are you seeing, specifically, so we can fix them.
Again, we should note that 5322 and 5321 have their own redundancies and
opportunities for inconsistencies.
Would that Postel and I had coordinated better for 821/822, but alas we didn't.
At the time, I thought we did, but it's been clear for a long time that we didn't.
I remember wondering about that at the time, but certainly had no concept of the
long-term hassles it would cause.
Kinda makes one appreciate the benefit of being more careful. We probably
should have taken another 10 or 15 years to figure it out...
In Section 1.2 of the draft, RFC2822.From and RFC2821.MailFrom are used to
refer to structured fields of a message. I prefer Header.From and
SMTP.MailFrom as it doesn't require any changes if RFC 5321 and RFC 5322 are
updated. There was a similar discussion about the replacement for
message/rfc822 in the EAI Working Group.
As I recall, the choice of "rfc#." versus "acronym." or "std#." was discussed
during development of the draft. Perhaps separately, but it has come up in
recent years.
From what I've seen, folks generally seem to prefer using the RFC number.
Personally, I'd prefer acronym#, although the other side of not having to make
changes when there's a new RFC is not being sure whether the meaning has
changed...
In the Security Considerations Section (6.1):
"As mentioned in Section 4.1.4, it is common practice for components of this
architecture to use the [RFC0791].SourceAddr to make policy decisions
[RFC2505], although the address can be "spoofed"."
As the focus of the draft is email architecture, this doesn't fit under
security considerations.
Email-arch discusses implications in various places. From what I've seen, the
IETF's security geeks vastly prefer having extra Security Considerations, rather
than missing important ones. And in terms of advising the community about
security holes in email, more is definitely better. So I'd rather see this
tidbit retained.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf