On Wed, 19 Nov 2003, Markus Hofmann wrote:
We are starting WG last call on the "OPES Callout Protocol Core"
draft (see attached). The last call period closes on Wednesday,
November 26 at 5pm EST. Please post any comments, etc. to the
mailing list, and please point out whether you feel your comment is
editorial or a show-stopper.
Below are my show-stopping comments for OCP Core. These are based on
the "Open Issues" list I posted earlier. That list, containing some
discussion about possible alternatives, is quoted at the end of this
message. The list is _not_ a part of the last call feedback.
S1. Explicitly document that OCP Core does not
require OCP connection encryption and does not
document encryption negotiation. Refer to
OCP extensions as places where encryption and
authentication may be documented. Do not
name specific OCP extension drafts since they
do not exist yet, and since we do not want to
end up waiting for their maturity to move Core
to proposed standard status.
S2a. Drop application message identifiers from
OCP Core. They are not used by HTTP Adaptation
draft; thus adapted am-ids are application-specific.
The Core already [correctly] says that
there can be only one original application message
that is being adapted in a given OCP transaction;
thus, original am-id is useless.
S2b. Replace xid atom with {xid} structure to allow
for seamless addition of adapted am-ids in OCP
application bindings such as SMTP/OCP.
S3. Similar to S2b, group related anonymous parameters
into structures. Specifically, (offset, size) pairs
and offset atoms must be grouped into corresponding
structures. This may simplify OCP extensions that use
additional ways of addressing [original] content (e.g.,
AM-Part-based addressing).
S4. Fix Protocol Element Type Declaration Mnemonic to
allow for extending message semantics without changing
message names. HTTP Adaptation draft already needs that,
not to mention that it is a PETDM design flaw.
N.B. I also have a rather long list of minor editorial changes. Since
I am the draft editor, I would prefer to type those in directly and
post a diff for those who care. Doing so will save me a lot of time on
describing those editorial comments in prose before applying them. If
you have any objections, please let me know ASAP; I hope to finish
editorial comments by the last call deadline at 17:00 EST.
Thank you,
Alex.
On Thu, 6 Nov 2003, Alex Rousskov wrote:
Hi,
Here are some OCP Core issues that may be worth discussing at
the upcoming F2F meeting. Since I will not be at the meeting, I
provided my current opinions on every issue. Please do not treat this
list as a formal request to add all of the items below to the agenda.
These are just suggestions. Meeting participants should decide among
themselves what, if anything, here is worth discussing in Minneapolis.
1. Agent authentication negotiation. Should it be
documented in the Core? Should it be required?
My current opinion is that there should be
a separate OCP Security draft because there
are several standard ways to do authentication
and at least two can be covered. Also, in-band
authentication should not be optional which
makes documenting such a big and independent
feature in Core inappropriate.
My second choice for placing this stuff
would be a Core Appendix. However, I expect such
Appendix introduce IANA considerations (registered
URIs and such), and that is awkward to do in the
Appendix. Also, it will delay last call for the Core.
2. OCP connection encryption negotiation. Should it be
documented in the Core? Should it be required?
My current opinion is the same as in #1, for same
reasons. Note that it is common to have security
covered in a separate draft(s). HTTP does that,
for example (RFC 2616, 2617).
3. Should OCP Core contain a full adaptation example?
It would have to be application-specific.
IMO, OCP Core can refer to a full adaptation example
in an adaptation draft such as HTTP Adaptation.
4. Should we solicit IETF SIRs review before going
into last call?
I would rely on chairs' opinion here.
5. OCP Core spends a lot of ink documenting application
message identifiers (am-ids) in various contexts. There
are original and adapted am-ids. HTTP does not use any
am-ids, essentially. We do not know of any protocol
that would need original am-id, but we still keep it
so that processor and server sides are symmetric.
The only reason to have adapted am-ids is to support
SMTP and other protocols that may have multiple adapted
dataflows for a single original dataflow. Yet, we have
no experience whether Core has enough stuff to accomodate
SMTP and similar needs. Should we yank am-ids from
the core and rely on OCP extension mechanisms if/when
we start supporting SMTP?
To make future extensions easier, we can replace current
"xid am-id" pair of anonymous parameters with a single
anonymous {xid} structure so that new members (e.g., am-id)
can be added to the structure without changing the overall
look and feel of any am-related message.
IMO, it may be a good idea to get rid of am-ids in Core,
but I am not sure at all and would like to hear others'
comments.
5a. Should we stuff all related anonymous parameters into
structures? For example, "offset size" can become
{offset size}. Again, the rationale would be to
simplify extensions of those parameters (e.g., adding
AM-Part to the structure) and to simplify extending
the anonymous parameter list in case one or more
existing parameters are optional.
IMO, if we do the changes suggested in #5, we should
do similar changes throughout the protocol.
6. Recent changes to the Core moved data preservation
maintenance out of Data Use Mine/Yours commands.
The rationale was that Data Use Mine/Yours commands
are specific to a single adapted dataflow while
data preservation maintenance applies to the
original flow and, hence, to _all_ adapted flows.
We should not confuse implementors with two different
scopes within a single message.
For example, callout server's preservation interest
is now expressed in a Data Preservation Interest
(DPI) message that refers to original dataflow only:
DPI: extends message with {
xid org-am-id org-offset org-size;
};
This used to be a part of the Data Use Mine/Yours
message (Wont-Use and similar parameters).
The problem with this approach is a loss of simple
optimization opportunities. Before, a Data Use Yours
message with a Wont-Use parameter would allow the
processor (recipient) to send the data out and
free the data as it sends. Now, the processor has two
choices: (a) send the specified data out and
wait for a DPI message to free the data later;
and (b) look ahead in hope to find a DPI message
right after the DUY message and free as it sends
if a DPI message follows.
The difference between freeing eventually and
while-you-send may be important. Depending on
an implementation, gradual freeing might mean 50%
more buffer space available (on average) to
share among data streams. Look-ahead optimization
sounds rather complex and error-prone to me.
Question: what is more important here: the clarity
of the protocol (the current spec is more clear) or
the free-as-you-send optimization (the old spec
allowed for that).
Moreover, in the old spec, the preserved data could be
freed by default when a Data Use Yours message is received.
Thus, there were fewer chances that a callout server will
"forget" to tell the processor that some data should be
freed.
Finally, if we go through with #5 changes, then
the whole rationale for factoring out data preservation
and similar information out of adapted dataflows becomes
less convincing because there is only one adapted
dataflow from Core point of view. On the other hand,
if we go back to the original scheme, SMTP and other
similar extensions would suffer from clarity point
of view (the rationale would still be valid for them!).
IMO, we should keep the current scheme, but I am not
sure at all and would like to hear other opinions.
7. Protocol Element Type Declaration Mnemonic (PETDM)
documented in Section 8 does not allow extending
message semantics without renaming the message because
the message name is the type name, and to extend
semantics one must change the type. For example,
an OCP extension cannot add a new parameter to
the message without renaming it.
IMO, this is wrong and must be fixed by somehow
isolating message guts from message name. It should
be possible to extend message.guts without renaming
the message.
8. Is Appendix A "Message Summary" needed?
IMO, we should keep it and add section references
if the plain text rendering can fit them.
9. Should we add an index (words linked to sections
where they are defined or talked about)?
I do not have a strong opinion here. We could.
I will post again if I can think of something else.
HTH,
Alex.