Re: [Spasm] comments on draft-ietf-pkix-eai-addresses-01

> -----Original Message-----
> From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Sean Leonard
> Sent: Sunday, May 22, 2016 9:12 AM
> To: spasm@ietf.org
> Cc: Alexey Melnikov <alexey.melnikov@isode.com>
> Subject: Re: [Spasm] comments on draft-ietf-pkix-eai-addresses-01
> 
> 
> > On May 21, 2016, at 1:51 PM, Alexey Melnikov <alexey.melnikov@isode.com>
> wrote:
> >
> > Hi Jim,
> >
> > On 14/05/2016 06:25, Jim Schaad wrote:
> >> 1.  This document has been expired for some time and thus should be
> >> republished if we are planning to use it as a starting point.  (If
> >> this is done the name would also need to be adjusted.)
> >
> > Yes, I will post draft-melnikov-spasm-...-00.
> >
> >
> >> 2.  The text about the format of an eaiMailbox name seems to be strange.
> >> Specifically, the text about what it does not have deals with display
> >> formats of an eaiMailbox and not it's format.
> >
> > This is trying to make the point that the syntax is as used in SMTP
> > protocol and not as used in similar slots in From/To/Cc/Bcc header
> > fields. Suggestions how to make this clear are welcome.
> >
> > If you think just deleting extra text is Ok, I can do that.
> 
> Actually (as the author of the new draft-seantek-mail-regexen-00) I disagree
> (fairly strongly) with this change.
> 
> rfc822Name is defined in terms of RCC 822 etc., not RFC 821 etc.
> 
> RFC 5321 imposes several restrictions on e-mail addresses, such as no C0 control
> characters (among other things), that are not present in RFC 5322 etc. The
> difference is that there are “e-mail addresses” and there are “deliverable e-mail
> addresses”. “Deliverable” in my definition means those that strictly conform to
> RFC 5321 etc., i.e., the “modern SMTP infrastructure”. But e-mail addresses as a
> class of identifiers, can include any character, including U+0000 NULL.
> 
> Actually however, a mail server *can* accept e-mail addresses outside the range
> of DEAs, as can systems that consume e-mail address identifiers for non-SMTP-
> mailing purposes (username identifiers, X.400 systems, etc.). In some cases it
> may be desirable to certify/use non-deliverable e-mail addresses for other
> purposes (compare, for example, with a PGP key with an e-mail address that an
> organization or individual uses “internally”, without any intent to receive e-mail
> at that address).
> 
> It is reasonable for a certificate to include the full range of e-mail addresses, not
> just “DEAs”. This is exactly analogous to the IP address fields in GeneralName:
> you can specify 0.0.0.0 or 255.255.255.255, even though those addresses are
> not “deliverable” (i.e., deliverable to a specific endpoint on the network). E-mail
> addresses that do not conform to RFC 5321, but do conform to RFC 5322, really
> should therefore be allowed.
> 
> I do agree with a restriction that says that e-mail addresses should be in
> simplified form, namely, have no extraneous whitespace and no comments.
> (RFC 5322 allows these but RFC 5321 does not; they do not add to the semantics
> of the identifier.)

I am not sure what you are saying is going to be covered by the removal of the text and what is not covered by the removal of the text.  I am worried that you are starting to move from the world of email addresses to NAI forms that are used by systems such as RADIUS, but we are labeling this as being an email address form.

I am not sure that I understand the reason that you are distinguishing between deliverable and non-deliverable addresses in this field.  Do you have an application in mind where non-deliverable addresses are needed?

Jim

> 
> Sean
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm