[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE : draft-ietf-opes-ocp-core
Alex,
Thanks for these usefull precisions.
Just about AM-part and processing points: I didn't thought about AM-part, but yes, it could match my need (even if it's need adaptation to DNS protocol to limit overhead).
However, I think we need at least a way to tell the processor if it's allowed or not to cache specific adapted data.
One example to explicit my need: having a filtering service, you may want unfiltered content (for any client profil) to be cached by the processor after the server call (to reduce load on this server), so the server has to be called before the processor cache mecanism. However, you will want potentially filtered content and corresponding adapted data not to be cached because it will be managed by specific server policy.
So I suggest introducing at least an optionnal flag in DUM message telling processor not to cache the answer.
Regards,
Karel
> -----Message d'origine-----
> De : Alex Rousskov [mailto:rousskov@xxxxxxxxxxxxxxxxxxxxxxx]
> Envoyé : lundi 25 août 2003 17:57
> À : MITTIG Karel FTRD/DMI/CAE
> Cc : ietf-openproxy@xxxxxxx
> 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.
>
>