On Sun, 15 Mar 2015, John R Levine wrote:
That sounds fine. Are you saying you prefer the document to not list the
example mappings we know about, or are you okay with still mentioning
the example mappings?
This whole can of worms needs attention from the people who think about mail
all the time. The RFCs are quite clear that mailbox namees are opaque and
clients are not allowed to make any assumptions that similar names are the
same mailbox. Servers can use CNAMEs to publish likely variants that people
will try, but I'm wondering whether it will still turn out to be too
frustrating to use.
That did not answer my question though. Do you prefer the example
mappings to be in the document or not? If a new document is started on
the issue of email address mappings, it should not stall progress on
this document. So I'm looking at text that points out the issue, yet
punts a solution elsewhere. I am thinking the current Section 3.1 with
only the last sentence changed could do that and this document can move
forward.
anything else that uses a hashed mailbox. This suggests if we go down
that road, the name management belongs in a separate document from the
definition of the RR type, and it needs attention from the SMTP crowd.
Agreed.
OK. Want me to split it out and do a draft? Can't submit it now but we can
talk about it in Dallas.
I think a clarification on the case sensitivity issue and the well known
mappings would be a useful document and I'm willing to co-author.
Personally, I would like to see some advise telling email clients not to
auto-capitalize the first letter in an email address input box for
example. (hint to Apple for iOS)
I don't think we could advise anyone on interpreting ".", "-" or "+"
other that text proposed by Wil along the lines of "Only support these
mappings when you _know_ the target domain performs these". Which is
what the last line in Section 3.1 should say as well.
Paul
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
