ietf-openproxy
[Top] [All Lists]

Re: Strawman OPES Charter

2004-07-13 10:05:59

At 16:33 13/07/04, Markus Hofmann wrote:
jfcm wrote:
I am disturbed by the imbalance. First was developped a profile for HTTP (a protocol), now we want to support applications (not a protocol) using messages transported by a protocol. What about messages supported by other protocols. This is one of the fall out of my remark about the judge analysis. If the messages are considered they could be transported by http, ftp etc.

So far, we've specified a OCP/HTTP profile that supports services operating on HTTP messages. Now we specify a OCP/SMTP profile that supports services operating on SMTP messages.

This is why the same phrasing should be used.

One of the key element in SMTP is routing. My main interest in OPES (as long as they do not support ONES and interoperations) is in massaging routing elements (what permits to correct DNS or SMPT recipient informations).
- is this included ?
- this may forbide the wording about one end to agree. Let say A send a mail to B and B (or law) wants an OPES changing B into C. The C real termination is not necessarily informed. Also correction is impossible since the mail information arrived to C is compromised. If C demands the OPES action to be corrected, C will nevertheless know what was in the message.

All future work will have to follow the one-party consent model, i.e. at least one of the ends has to authorize the servive (this, of course, can be done implcitily).

The answer does not match the question. In one to one direct access http, I know who are the parties. I one to many possibly rerouted mailing I do not know what you mean by parties. Has to be clarified otherwise the whole thing will be opposed on security grounds.

My Franglish is lost. HTTP/SMTP messages ?

That is meant to say "...HTTP or SMTP messages". Will change that.

I am not sure about what you mean in this as SMTP Messages when you refer to HTTP Messages. You will find that SMTP will probably used in OPES related application as application signal and message transport. Even if you do not want to take theses mechanisms in consideration, what IMHO removes a lot of interest to effort when you consider real life applications - for example spam fighting, I suggest a clearer wording to avoid this confusion.

Cheers.
jfc