-----Message d'origine-----
De : Alex Rousskov [mailto:rousskov(_at_)measurement-factory(_dot_)com]
Envoyé : lundi 25 août 2003 17:57
À : MITTIG Karel FTRD/DMI/CAE
Cc : ietf-openproxy(_at_)imc(_dot_)org
Objet : Re: draft-ietf-opes-ocp-core
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.