Subject: WG Last Call: draft-ietf-opes-ocp-core-03.txt

From: Markus Hofmann <[email-masked]>
Date: Wed, 19 Nov 2003 16:36:03 -0500

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.

Thanks,
   Markus

Subject: I-D ACTION:draft-ietf-opes-ocp-core-03.txt
From: [email-masked]
To: IETF-Announce: ;
Cc: [email-masked]
Date: Wed, 19 Nov 2003 15:28:17 -0500
List-Id: <ietf-openproxy.imc.org>

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Open Pluggable Edge Services Working Group of the IETF.

	Title		: OPES Callout Protocol Core
	Author(s)	: A. Rousskov
	Filename	: draft-ietf-opes-ocp-core-03.txt
	Pages		: 69
	Date		: 2003-11-19
	
This document specifies Open Pluggable Edge Services (OPES) Callout
Protocol (OCP). OCP is an application-agnostic protocol that
facilitates exchange of application messages between an OPES
processor and a callout server, for the purpose of adaptation of
application messages at the callout server.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-opes-ocp-core-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-opes-ocp-core-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-opes-ocp-core-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 26 Nov 2003 00:42:36 -0700 (MST)

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.
>

---

From: Markus Hofmann <[email-masked]>
Date: Wed, 26 Nov 2003 10:59:11 -0500

>        thus, original am-id is useless.

What about multiple am-ids for the responses coming back from the 
callout server (possibly required for SMTP)? Will this still be 
documented in OCP core or moved out to application-specific bindings?

>        application bindings such as SMTP/OCP.

OK, I believe that answers my question above... OCP core will *not* 
document am-ids, but define a structure that allows 
application-specific bindings to include such am-ids for responses, right?

> post a diff for those who care. 

That's fine.

> Doing so will save me a lot of time on

Alex, when will you be able to address your show-stopping comments in 
thedraft? If no one objects to your comments/suggestions in your 
earlier email, please go ahead and merge them into the draft. We'll 
then issue (the hopefully final) WGLC on this draft.

If someone has objections to what Alex outlined, please raise your 
concrn NOW!

Thanks,
   Markus

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 26 Nov 2003 10:03:52 -0700 (MST)

> documented in OCP core or moved out to application-specific

The possibility of multiple responses will remain documented. The exact
mechanism (am-ids) will not be.

> application-specific bindings to include such am-ids for responses, right?

Exactly.

> then issue (the hopefully final) WGLC on this draft.

Given impending holidays in the US, I am uncertain about my
availability for the next 4 days. I will do my best to apply
everything by Tuesday morning, hopefully sooner.

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 26 Nov 2003 14:50:01 -0700 (MST)

Hi,

	One more issue has just cropped up while I was applying
editorial changes. It probably has status above "editorial":

	S5. Remove overlap between DIY and DWOL semantics.
	    Resolve 206 response status code ambiguity by
	    adding a "you can stop sending data now" message.

OCP Core defines Ignoring Your Data (DIY) and Want Out of the Data
Loop (DWOL) messages. Both are sent by the callout server to indicate
disinterest in original data (DIY and DWOL) and to indicate desire to
quit sending adapted data (DWOL only). The processor can stop sending
original data by responding with Application Message End (AME) message
with 206 (partial) status code. In case of DIY, a 206 response means
that there will be no more original data. In case of DWOL, the same
response means that there will be no more original data _and_ that the
server may get out of the loop.

The above description clearly shows the overlap in DIY and DWOL
semantics; both messages mean, in part, "I do not care about original
data". This creates problems because the two messages cannot be
combined on the same transaction (that would make 206 response
ambiguous). If they are combined, it is not clear what the processor
has to do (short to bailing with an error).

The solution is to remove "I do not care about original data" from the
DWOL logic. We need two separate messages: "I do not care about
original data" (current DIY) and "I would rather not send you original
data". Combined, the two can implement current DWOL logic, but they
are useful in isolation as well.

Finally, a "you can stop sending data now" message should be added so
that the processor can inform the callout server that the server can
quit and processor would not mind. This will remove overloading of the
206 status code we have now.

This is not a big change, but it probably goes beyond editorial status
so I wanted to post it before the deadline in case there are any
objections or improvement suggestions.

Thank you,

Alex,
10 minutes before the last call cut-off deadline!