Austin,
With the understanding that this is just my personal opinion,
and perhaps more to others than to you, I think this
conversation has outlived its usefulness for several reasons.
In no particular order:
(1) The real history of email (and modifications/ extensions to
most other Internet applications) is that an innovation has to
be either (i) extremely easy to deploy and obviously readily
compatible with the installed base or (ii) a _huge_ and obvious
improvement to deploy quickly, or even at all. Instead, we
have seen a very large number of proposed improvements to and
replacements for the basic 822 model come and go. Even those
that were clearly superior along one or more dimensions have
disappeared because it hasn't met one of those criteria. Your
language and method do not appear to meet the first criterion;
you are wildly more optimistic about the second than the vast
majority of the more experienced folks here.
(2) Your questions and comments have shifted from "please review
this technical proposal" to what seems like a passionate
marketing campaign for a particular idea. It makes no
difference whether that has occurred as a direct consequence of
your actions or as part of people's attempts to explain that
deployment situation --as part of the whole system in which an
innovation within an existing application must exist-- to you.
Beyond some point, it isn't useful. And we are past that point,
IMO.
(3) Your draft doesn't contain even a hint of a transition/
deployment/ interworking-with-installed-base analysis. The
closest you come is with such statements as "Data transmitted by
this object using RFC 5322 conformant headers SHOULD NOT expect
successful or accurate interaction with the intended document"
which, to me, suggests that the transition model is "either use
the existing plan or use the new one, but they don't really
co-exist except maybe at the transport level". That doesn't
predict to easy and seamless deployment. While such an
analysis is not procedurally required, I suggest to you that it
needs to be present for the work to be taken seriously... and
that many of the comments you have received are indicative of
the fact that it is not.
In that regard, you might find it helpful to study the archives
of the "EAI" WG and its struggles to design and deploy an
extended email address syntax --in principle, a far narrower
change than the one you are proposing and for a purpose that is
far more obvious to a large fraction of the Internet user base--
to get a sense of how seriously those issues need to be taken.
(4) Although your abstract suggests that security is a lot of
what this proposal is about, your actual "Security" section is
woefully inadequate. It does not discuss attack scenarios, the
difficulties imposed by a processing model in which the remote
user has to just trust that the sending user has not tampered
with the local client (I'm not an expert in these things, but
statements like "The user MUST NOT be allowed to interfere with
the processing of such instructions" appear to me to be fairly
vacuous in the absence of a multilevel-secure, ring- or
domain-isolating, operating system), the well-known problems
with key management by end users in a PKI environment, and so
one and so forth.
(5) One very good symptom of uptake of a new idea in the IETF is
that people come forward and offer to help work through details
and construct text to refine the rough edges of the proposal. I
haven't seen that happening here even though you have gotten
several constructive comments. Perhaps you should take that as
a symptom of, e.g., what would happen if you proposed a working
group to standardize this work. On the other hand, if your
intention is just to get comments rather than to move toward
treating the proposal as an IETF work item, the use of an IETF
list and I-D postings to solicit comments rapidly becomes
abusive. You are, IMO, close to, if not well past, that line.
(6) One of your recent notes includes the comment:
The language I created does contain some patent pending
features, so perhaps in three to five years after the US
Patent and Trademark office concludes an investigation we will
know for sure.
Your Internet Draft contains a statement of "full conformance
with the provisions of BCP 78 and BCP 79". The above indicates
that you are somewhere in the process of filing for patents.
There is no disclosure on file as required. Your "mail markup
language" draft, while apparently never posted as an I-D (and
containing statements that indicate that it is one), contains
the equivalent statements and your discussions and the
references in "draft-cheney-safe" certainly constitute
introducing it into the IETF. That document contains some
rather specific and possibly restrictive IPR claims, further
increasing your obligation to make disclosures as required by
BCP 78. I am not a lawyer, I would certainly not be
representing you if I were, this is not legal advice, and you
need to consult your own patent counsel on the subject, but
there is some history that introducing something into a
standards body without meeting its IPR disclosure requirements
can render the patent unenforceable.
I also observe that the "Note Well" to which you agreed when you
joined this list digs you deeper into that problem with regard
to both documents with every posting to the list. My
recollection is that your use of an "army.mil" address for these
discussions creates some further complications in that regard,
but those are issues that are best discussed with your attorney
and/or commanding officer.
I think that it is past the appropriate time for you to make the
relevant BCP 79 disclosures about this material and that you are
now seriously overdue, that you need to be much more clear about
your intentions along the dimension that stretches from
"proprietary protocol or product" to "intended standard", that
you either get the "Mail Markup Language" draft properly posted
as an I-D or stop pulling it into these discussions, and/or that
you take the discussion elsewhere.
john