Re: Last Call: <draft-ietf-uta-email-tls-certs-05.txt> (Updated TLS Serv

I donot see attachment on the ietf website in list archive. Is
attachment not allowed?

Attaching again

On Fri, Nov 20, 2015 at 6:34 PM, Samir Srivastava
<samirs(_dot_)lists(_at_)gmail(_dot_)com> wrote:
> Sorry the attachment is the application for impeachment of President
> USA in which Supreme Court did not do anything.
>
> On Fri, Nov 20, 2015 at 6:26 PM, Samir Srivastava
> <samirs(_dot_)lists(_at_)gmail(_dot_)com> wrote:
> > Sorry I donot have time to change the subject. Can Protocol become
> > science. Our understanding of the problem domain is incorrect.
> > Pl refer the attached provisional patent application.
> >
> > I am on the protest at 3245 NW 31st Terr Oakland Park FL 33309.
> >
> > I am facing lot of issues. Pl help me. I will provide the patent
> > details in the next email, if I am okay.
> >
> > I wanted to make protocol as science.We need to stop working on flurry
> > of the documents. When I was working on Cashless Economy, the money
> > earned I wanted to fund this. But I am stuck with big powers so I am
> > left with no other choice to fight this battle in court.
> >
> > Thanks
> > Samir
> > Who hated patents embedded in standards
> > Refer the blog http://samirsrivastava.typepad.com/
> >
> > On Fri, Nov 20, 2015 at 4:36 PM, Russ Housley 
> > <housley(_at_)vigilsec(_dot_)com> wrote:
> > > I support this document going forward.  Below I suggest four improvements 
> > > to the document.
> > >
> > > (1)  In Introduction says:
> > >
> > >    Note that this document doesn't apply to use of TLS in MTA-to-MTA
> > >    SMTP.
> > >
> > > Can this be enhanced to include a pointer to where this can be found?
> > >
> > >
> > > (2)  The next paragraph in the Introduction says:
> > >
> > >    The main goal of the document is to provide consistent TLS server
> > >    identity verification procedure across multiple email related
> > >    protocols.
> > >
> > > Since this is a standards-track document, I think it would be better to say:
> > >
> > >    This document provides a consistent TLS server identity
> > >    verification procedure across multiple email related protocols.
> > >
> > >
> > > (3)  Section 2 does a lot by reference, which is fine.  I think it would 
> > > help the reader to duplicate a bit of context from RFC 6125, in particular 
> > > repeating the definitions of CN-ID, DNS-ID, and SRV-ID.
> > >
> > >
> > > (4)  Section 3 needs to state first that the certificate passes 
> > > certification path validation as described in Section 6 of RFC 5280, and 
> > > second passes the email-specific rules in this section.
> > >
> > > Russ

Letter Copy (1).pdf
Description: Adobe PDF document