ietf-openproxy
[Top] [All Lists]

Re: where is OPES?

2006-01-30 10:19:23

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


<Prev in Thread] Current Thread [Next in Thread>