Tony Hansen wrote:
This means *you*. For those of you looking over your
shoulders right now to see who else I might be talking
to, stop looking any further; I really do mean *you*.
No, you don't, it clearly says "readers are expected to be
familiar with a ton of other documents", and I'm not.
Some observations _without_ looking into the other drafts:
s/ lised / listed /
| the email body again can be divided into several sections.
Anything beyond MIME parts is probably hopeless.
| RAWDATA: The complete mail data which is sent AFTER the DATA
| command (see section 4.1.1.4 of [RFC2821]).
Don't forget BDAT and BURL - also a chance to find 'sections'
(BDAT chunks) that are not MIME parts. In addition to stuff
like message/partial or message/external-body (at least the
former is a known security risk - reject, reject, reject -
the new mantra of SMTP).
| SECTIONS: Sections of the email body (for example MIME
| sections), each to be sent in a separate OCP message.
There's no such thing as a MIME "section", it's called "part",
and it's a recursive data structure.
| Example 1: P=OPES processor, S=Callout Server
| P: NO ({"38:http://iana.org/opes/ocp/SMTP/receiver"
| Adaptive-Commands: (RCPT,DATA)
| Informative-Commands: (IP,HELO,MAIL)
There's no "IP" and no "DATA" in the 3.1 list. But probably I
just don't get the idea of the complete draft,
Section 3.3.4 says that it's incomplete. BTW, did the SIEVE
and LEMONADE folks see anything of this ?
s/the the EHLO response/the EHLO response/
3.4.1: Not sure if that's good enough for BDAT and BURL.
It also doesn't address STD 10 SOML / SAML instead of MAIL.
3.5 says TBD.
4.2 talks about "SMTP Service Extension for OPES Trace and
Bypass [to be done in external document; referenced from here]"
7 (security considerations) doesn't mention message/partial,
message/external, or convoluted MIME boundary values, for the
latter compare draft-ietf-usefor-usefor-06.
There are no IANA considerations for the new OPES-System: and
OPES-Via: header fields (RfC 3864), or are they elsewhere ?
Nothing about I18N wrt "replace body by error message", or
wrt 2231-encoded words in header fields. Nothing about the
various interesting MIME types, above all the Content-Type.
s/RFC2396/RFC3986/
It's time to get this one out the door.
Certainly not as is, depending on the door of course. Bye