Could I ask the list sergeant-at-arms consider remonstrating with the
poster below on the content of his posts and, if not satisfied with the
response, initiate a posting restriction action.
Thanks - Mike
On 11/21/2015 7:40 AM, Samir Srivastava wrote:
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