Dear Stephen, Thank you very much for your thoughts, but i do not think we can move the discussion ahead when it stops with non-technical opinion dropping statements like "lets not play games" (you) or "i do not think this is the right thing to do" (Ben/Russ).
Could you please explain your assertion with technical arguments ? More inline On Tue, Jun 23, 2020 at 07:52:25PM -0400, Stephen Kent wrote: > Brian, > > Common sense argues against putting something other than an e-mail address > > in the rfc822namem attribute. > > > > I expect ADs to use common sense, as well as careful reading of prior RFCs, > > when making decisions. > > Indeed, but that cuts both ways, since running code is our goal. No parser > > is in a position to say that > > rfcself+fd89b714f3db00000200000064000000+area51.resea...@acp.example.com > > isn't an email address. > > If we were only AIs that would be a suitable reply ;-). I can only guess what this mean. You don't like the look of it as a human ? I for once have been confused a lot by solutions where some data only have a well-defined binary representation for "AI" ? to handle but none for humans. In result, those solutions all are IMHO hard to troubleshoot, because every CLI/GUI software came up with its own representation. For information which naturally represents the domain, name and role attributes of an entity, there is IMHO no better human recognizable standardized representation in a single string than using the local-part@domain format. ACP nodes in the acp.example.com domain only have one name, which is their registrar assigned IPv6 address, therefore [email protected] really is the most human readible representation of that identification i can think of. [email protected] The rfcSELF is just a prefix to allow isolation of namespaces in the local part. Think of [email protected] vs. [email protected] Likewise the +area51.research is just like a department name, [email protected] A lot more legible than what poor network operators would normally see IMHO. > But, we're not- we all know that the proposed IDs are NOT rfc822 addresses, > so let's not play games. This is not meant to be playing games. These are syntactically perfect rfc822Names/ email-addresses and semantically they can be perfect electronic mail boxes. Remember that as the draft explains also in section 6.1.2, there is good amount of prior examples where local-part@domain is used as just identifiers without using any email boxes in the process. For example inter-domain access authentication, eduroam or the like. [ Then again, IMHO IETF is also supposed to develop new technologies, so i am not even sure why i always end up having to argue that solutions are better because they don't do something fundamentally new.] > The simple answer is that when, in the past, developers have chosen to abuse > the semantics of subject name fields in certs, the result shave been VERY > long lasting, and embarrassing. Long ago, Netscape chose to shove a DNS name > into the DN common name filed because it was an easy fix for their problem. > As a result, we still have browsers and CAs that misuse that field. At least > that egregious behavior was not the result of an IETF WG. Let's not screw > this up in the name of expediency! I have also not seen a reply from you to Michael Richardsons question about that statement. I am not aware of the history, so i can not comment, but i am curious about your reply. Nevertheless, i do not think your example has any relevance here, because we are not choosing a potentially wrong encoding for an existing piece of information, but we are arguing that our strgins are are perrfectly syntactic and semantic correct electronic email addresses and therefore deserve to use the standard encoding for electronic email addresses. Cheers Toerless > > Steve > > _______________________________________________ > Anima mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/anima -- --- [email protected] _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
