On Mon, 25 Aug 2003, MITTIG Karel FTRD/DMI/CAE wrote:
I'm actually working on a generic OCP implementation for a later
adaptation to DNS services. In this context, I have several comments
on actual draft, which I hope will help you to clarify or modify it:
Glad to see more people interested in OCP and appreciate your
comments! Detailed responses are below.
DUM=>'as-is'
--------------
"as-is" includes an "am-id" parameter. What is the range of this
am-id: AM session or Transaction ? If it's only available in current
AM session, why using it when it's already present in DUM anonymous
parameters ?
Anonymous am-id parameter of DUM message identifies the _adapted_
application message within the transaction. There may be several
adapted application messages within a single transaction for protocols
such as SMTP. Am-id field of the "as-is" parameter identifies the
_original_ application message within the transaction.
For now, there can be only one original application message within a
transaction, but that might change. Even if it never changes, it's
good to keep original am-id in the protocol to keep original and
adapted data messages symmetric (IMO).
Do the above statements answer your questions?
DUM=>'ack'
--------------
DUM 'ack' can be send by both processor and callout server, but DACK
messages can only be send by callout server. Draft modification
needed to make DACK sendable by both ?
I think you are right. Data acknowledgment mechanism should be
symmetric. Added to the to-do list.
BTW, I suspect it would be better to make the mechanism more universal
so that any message can be acknowledged, not just DUM. We already have
a problem with DUY messages that cannot be acknowledged. Unless I hear
objections or better ideas, I will try to make the acknowledgment
mechanism work with any OCP message.
DH:
--------------
First draft version was including DH message, which has been removed
in the last version (replaced by ack flag in DUM message as I
understand). However, several parts of the draft still refer to DH:
-DACK
-Adapted dataflow definition
-Message Examples
Indeed. The next draft version should have all DH references replaced
with DUM. Please let me know if you find more leftovers after the next
release. It is mostly a text management issue -- I still need to find
a way to use some kind of XML placeholders with xml2rfc instead of
actual message names, to better track name usage and reduce renaming
problems.
DACK
--------------
DACK description speak about a "please-ack" parameter which is not
defined anywhere else. Also, the aim of "wont-forward" parameter is
not clear to me. If it's only used to terminate preservation
commitment, why not re-using the "wont-use" parameter ?
Renamed "DUM.please-ack" in DACK description to "DUM.ack".
Note that wont-use has a very different semantics: The ack parameter
of a DUM message asks the recipient to acknowledge that the message
has been received. The wont-use parameter informs OPES processor that
a portion of the original data kept at the processor will not be used
by the callout service (and, hence, does not need to be kept any
longer).
PONG/PING
--------------
rid named parameter => obsolete ?
Removed for now. I think we may need it later, but it is possible that
we can merge the ping/pong and DACK mechanisms together and remove at
least one of the ping/pong messages. See above comments regarding DACK
future.
Name of [xid[am-id]] named parameter is not defined
These will be anonymous parameters in the next draft release.
NO/NR
--------------
ocp core draft defines anonymous parameters as a list of
features(§8.13), while HTTP adaptation uses a list of services(§8.4)
instead. Which one is right ? :-)
Both are correct, in principle. A "feature" is a generic mechanism
that HTTP uses to negotiate "services". In other words, "service" is
one of the "features" that can be negotiated.
In NR, named parameters "Rejects" (which is normally indicated by
omitting the "feature" parameter) & "Unknowns" are not defined.
Will document for the next release:
When accepting or rejecting an offer, the sender of the NR message
MAY supply additional details via Rejects and Unknowns parameters.
The Rejects parameter can be used to list features that were known to
the NO recipient but could not be supported given negotiated state
that existed when NO message was received. The Unknowns parameter can
be used to list features that were unknown to the NO recipient.
Note that even a positive NR response may have rejects and unknowns.
FLAGS
--------------
"flag" named-parameters (error, ack & wont-forward) type is not
clear. Normally, it should be boolean ("0"/"1", correct ?) but this
is not explicitly defined.
True. Added to the to-do list. "0"/"1" would work. An alternative is
to say that a present flag name means "true" and an absent flag means
"false" (and have no value when the name is present).
Data syntax
--------------
Result parameter is defined like for example {200 "2:OK"}. However,
Martin presents on his OCP sample a {200 OK} result. Is it an error
or are both solutions possible ? If true, it will need useless
syntax checks, introduce possible errors in implementation and
should be avoid (in my opinion).
{200 "2:OK"} is correct, {200 OK} is wrong, IMO. Both are
syntactically valid, but we need to make it clear somewhere that only
one form is valid because "OK" is a string, not a token.
Named parameters use indifferently lowercase or uppercase ("Kept",
"modp","Error", "sizep"). Knowing that the protocol is
case-sensitive, it would be clearer to use the same nomenclature for
all parameters (everything in lowercase for example).
Yes. I think we are quite consistent with message names, but named
parameters need more work. Use named constants rather than hard-coded
strings in your code :-).
Last point is about processor management of server "adapted" data,
using processing points defined in "draft-beck-opes-irml" (adding
maybe 2 more points corresponding to processor core treatments
between 1->2 and 3->4).
My idea is to add an optional parameter in DUM message (something
like [next-processing-point: value]). Receiving this parameter,
processor SHOULD transmit adapted message to given processing point.
I am not very fond of the "processing points" approach because it is
very rigid and application-specific. Some application/protocols may
not have processing points (have one processing point). Some protocols
may have processing points that are not appropriate to enumerate as
integers or that change dynamically.
And perhaps more importantly, it seems wrong for the callout service
to tell processor which processing point to use next -- even if the
callout service knows a lot about processing points at the processor,
it cannot know whether adapted data it returns has to go through some
more adaptations before being directed to a given processing point.
This will allow for example a filtering service to tell the
processor (a proxy in this case) to directly answer to a client with
a denied message (with or without allowing processor to cache the
answer), or another service to tell the processor (server or proxy
in this case) to get another content instead of the one provided in
the answer, etc.
I do agree that supporting service-generated responses to client
requests is a MUST-have for HTTP adaptations. I hope we can do that
using application message parts concept (AM-Part): if processor is
receiving response parts when adapting a request, it would know that
the service is generating a response and would route that response
accordingly. Would that approach work well for you?
Thanks again for your comments and bug reports,
Alex.