+1 (or several)
john
--On Saturday, November 21, 2015 12:00 -0500 Mike StJohns
<mstjohns(_at_)comcast(_dot_)net> wrote:
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