Subject: where is OPES?

From: Tony Hansen <[email-masked]>
Date: Wed, 25 Jan 2006 13:52:43 -0500

The current charter for OPES lists the following three items, all
dealing with SMTP:

Mar 06 Submit document on OCP/SMTP profile for MTAs, including
       mechanisms for tracing and bypass, to IESG for Proposed Standard.

The Scenarios and Use Cases draft is now in the RFC Editor queue. We can
check this one off.

Mar 06 Submit document(s) on OCP/SMTP profile(s) for those
       other SMTP agents the WG has decided to work on, if any, to IESG
       as Proposed Standard(s).

There is a draft profile document, draft-ietf-opes-smtp-00.txt, that has
received little comment. It needs to be reviewed with the use cases in
mind, updated and last called.

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*. It's time to get this one out the door.

Mar 06 Consider additional OPES work such as extension to
       traffic beyond HTTP and RTSP and present new charter to IESG, or
       conclude working group.

My opinion is that this group has extended past the point of ennui. At
this point, I don't see any further work occurring in this group as a
chartered working group, and it *needs* to shut down.

If there *are* people interested in further work on the topic of opes,
it can be done using individual submissions. The mailing list will
remain open for discussions of such submissions.

Right now, I don't see the need for the OPES group to meet in Dallas.

If you have comments on *any* of the above, *please* send them to the
OPES group list, [email-masked].

	Your friendly co-chair,
	Tony Hansen
	[email-masked]

---

From: jfcm <[email-masked]>
Date: Wed, 25 Jan 2006 23:18:49 +0100

>OPES group list, [email-masked].

Tony,
I agree with this. But I *have* interests I expressed for years. 
These interests have not been followed on this list because they do 
not fit the current charter and the vision we initially agreed. I 
accepted it but I am afraid the ennui is the consequence. May be my 
vision and the lack of time (as you may know I am victim of a time 
wasting commercial/political DoS :-)) will lead to the same ennui. 
But if this group is to stay as a SIG without a real charter, would 
it not be an acceptable kind of topic?

I note that my vision (already documented in the past) calls for 
architectural considerations. It considers OPES and ONES (Open 
Network Extended Services) as a way to respect the end to end 
principle but also to provide network intelligence. I also note that 
I introduced an appeal to the IAB to ask if the 
Multilingual/Multilateral Internet was an IETF matter or not. I 
consider ONES as necessary to that architecture. If the response of 
the IAB matches the IESG first negative response, I will deal with 
the issue through an International Network usagge TF we plan to 
maintain a documentation on the entire digital convergence, from a 
user point of view.

I would suggest the IETF keeps this mailing list for topics like 
that. As an observatory SIG. If a Draft is introduced, some members 
could interested working on it as an individual common text?
jfc

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 30 Jan 2006 17:55:31 +0100

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