Subject: OCP Core issues for f2f discussion

From: Alex Rousskov <[email-masked]>
Date: Thu, 6 Nov 2003 10:08:37 -0700 (MST)

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.