Hello,
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:
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 ?
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 ?
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
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 ?
PONG/PING
--------------
rid named parameter => obsolete ?
Name of [xid[am-id]] named parameter is not defined
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 ? :-)
In NR, named parameters "Rejects" (which is normally indicated by omitting the
"feature" parameter) & "Unknowns" are not defined.
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.
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).
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).
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.
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.
Regards,
Karel
[France Telecom R&D ]