On Sat, 17 Jul 2004, jfcm wrote:
OPES are violating the principles of the Internet. This is not that
much visible with HTTP because HTTP is real time one end to one end.
On can support the idea that OPES is a nasty idea, or that the
Internet is "broken" (limited). I support the second one.
... Or that there is no violation if the principles of the Internet
are interpreted in the current context rather than read literally. I
think that's the only way to meaningfully interpret any principle, and
I dare to say that IAB is using that "context interpretation" approach
in RFC 3238.
If something is already broken, OPES should not be expected to fix it.
This is not a good response - or stop working on them.
Done! We are not working on fixing application protocols. We are
working on creating new functionalities on top of those protocols, in
environments where those protocols are not broken or will be fixed (by
others).
OPES can provide limited answers to needs the Internet cannot
address. But they do it in breaking the architectural principles of
the Internet (protocol on the wire, end to end, smart host/dumb
network, ... etc. please refer yourself to Harald's IETF mission
Draft "core principles").
Please refer to RFC 3238 for interpretation of those core principles
in OPES context.
No to waste our time and to provide a good service, we can work
on where your OPES concepts can provide solutions,
_within_the_limits_that_an_internet_architecture_permits_.
The charter must define these limits.
IAB has defined those limits in RFC 3238. Do you think we need to add
additional limits? If yes, what would those additional limits be?
- Either we work on SMTP Mail part and the mails are massaged when
stored on an agent, we are outside the network (you defined the OPES
that way against my suggestions). OCP is used for its qualities.
I do not understand the "SMTP Mail part" scope. I also do not
understand "stored" in this context. Can you define those two in OPES
context? For example, current OPES protocols do not depend on whether
somebody considers the application message "stored" or "in transit".
Why are you talking about "stored" messages? What is so special about
them that is relevant to OPES?
- Or we work on SMTP Transfer part and only the headers are massaged
and this corresponds to a gigantic extrension of the SMTP protocol.
I suppose several other WG will be interested.
I do not understand the "SMTP Transfer part". I am not sure why we
would want to limit ourselves to adapting MIME(?) headers only.
Translating e-mails at recipient's request, for example, sounds like a
good use case for modifying more than just headers.
- Or we work on an hyper-inter-complex-mail-transfer protocol as you
plan. OK.
Not sure what you mean here.
You ask for an example. Please tell me what in the charter
would prevent me to take the expected result and build a good and
complete working model of the world's evolution since the Big Bang.
Just HICMTP and OPES.
Not sure what you mean here. I am asking for examples of problems that
we should fix in the charter. I am not sure how world's evolution is
related to that.
Again, I have nothing against it (I presisely think _it_is_ the way
it works(ed)). But I feel a first attempt calls for more precise
boundaries or explanations and - even if you dislike it - to tell
what OPES are.
I believe that OPES Architecture draft, with all its limitations, sets
some boundaries and (with the Use Cases draft) provides some
explanations. To provide more precision, we would first need to agree
on where we currently lack precision. If you can identify specific
boundary problems, we can try to address them.
After all, all what I am trying to do is to avoid you waste your
skills, time and OPES/P/OCP image just because you will deliver a
good 1% of what you claimed you would. Spend a little more time in
defining your target as 1% so you will be thanked for delivering
100% of what you promised.
I cannot spend more time on solving an unidentified problem. If you
see a problem, please define it so that we can discuss and solve it.
The level of the problem can vary from architecture to protocol
specifics. It can be an OPES scope problem, an OPES architecture
problem, an OPES charter problem, an "SMTP adaptation problem", or
whatever, but you have to tell us what exactly we should fix or
improve.
And, for the record, since it did come up before, "what is OPES?" is
not a problem. It is a question already answered in OPES WG documents.
If you do not like the answer, please explain what needs to be
fixed/added to that answer so we can work on that.
Thank you,
Alex.