ietf-openproxy
[Top] [All Lists]

RE: OCP Core version head_sid6 available

2003-05-20 09:04:13

On Tue, 20 May 2003, Martin Stecher wrote:

- New-Line syntax:
<snip>

I agree with your comments and will fix the BNF like you suggested
below.

- Abbreviations:

I cannot find guidance whether message-name, message-abbreviation or
both can be used. I assume that abbreviations can be used. But does
it make sens to allow both variants? Full names are easier to read
but if abbreviations are allowed, many implementors will choose this
so that debugging will need to deal with abbreviations anyway. Why
then forcing implementors to support both. I vote for only using the
abbreviations (see proposed syntax below)

The current text lacks any guidance due to time constraints.  Some
rules must be added, of course. I agree that it makes little
implementation sense to support both abbreviated and full versions. I
am not sure what is the best way to eliminate full names from
implementations while having both computer- and human-friendly version
documented. Here is what I was going to add to the draft as the first
attempt:

        1a. Implementations MUST send and recognize abbreviated names.
        1b. Implementations MUST NOT send or recognize full names.
        2a. Full names exist exclusively for human-friendly interfaces.
            Documentation and debugging tools may use full names. For
            example, most examples in this specification use full
            names.
        3a. Abbreviations are collision-prone.
            Extensions outside of IETF standards track MUST NOT
            invent new abbreviations.
        3b. IETF standards track documents MAY add new abbreviations.

I think this matches your proposal. However, I am worried that if we
write examples with full names, implementors will start sending them
on the wire. And if we avoid full names in examples, does it make
sense to document full names at all? What do you think?

Perhaps we need a better term for "full name" and "abbreviated name"
to emphasize that only the latter can appear on the wire?  "Command
name" and "command code"?

- Message trailer

I like the dot as a native character to make stop a message but I
share your concerns in the note at the end of page 12. What about
using the exlamation mark character as message trailer? (see
proposed syntax below)

That would work and is probably better than any other single
character. Do you not like the {curly braces} approach though? Here
are the current options to consider:

        0. name parameters payload .        (current syntax)
        1. name parameters payload !        (Martin's proposal)
        2. {name parameters payload}        (XML-like)
        3. name parameters END              (BEEP-like)

If "." is to be replaced, I slightly prefer "{}" over "!". "END" seems
too wasteful to me. Other opinions?

- Proposed syntax change:

  message = name-abbr. [anonym-parameters] [named-parameters] [payload] "!" 
CRLF
  payload = CRLF data
  named-parameters = *named-parameter
  named-parameter = CRLF name ":" SP value

Agreed, except lets wait for more feedback regarding the terminator
choice above.

Also, the named-parameter syntax allows only for one value. Do you
think we should change that to

        anonym-parameters = values
        named-parameter = CRLF name ":" values
        values = 1*(SP value)

to better match MIME capabilities? Or is one value per name enough?

- Case sensitivity

The hint that OCP names are case sensitive is quite hidden at the
end of section 3. Better move it to a more prominent place, maybe
just on top of the message syntax.

Will fix.

- payload

I found several HTTP and ICAP programmers being confused that chunk
size in these protocols is given in HEX digits while the
Content-Length header is decimal. I think we should stick with
decimal. Hex will usually not save more than one char.

OK. Let's leave it as decimal unless somebody else objects.

- payloads

Is it possible that a message could benefit from multiple payload
parts following each other as in chunked transfer encoding? Or will
those cases always be mapped to multiple data-have messages?

Yes, always mapped to multiple data-have messages. The data-have
message overhead is so small that (IMO) it is better to keep things
simple: one message, one payload.

- connection-start

I wonder whether we could need a version number. Shouldn't we add
one to the connection-start message? It may be useful in future.

I would like to avoid versioning and use profile negotiations instead.
We have to support negotiations anyway. As far as I can tell, there
are two reasons to add versioning: support changes in message syntax
(major version change) and support new minor features/defaults (minor
version change). The former should not be done through versioning
(IMO). The latter is better done through profile negotiation (IMO).
Other comments/opinions?

If services is an optional xaction-start parameter, why not also
make it an optional parameter of connection-start? If OPES processor
wants to use the default service for a connection feature, it could
set it already with the connection-start message rather than sending
an extra connection-services message. Same for connection-priority?

I agree that the current specs are inconsistent. I am not sure what
the right fix is though. We can limit support to a dedicated message
for each state change (e.g., connection-priority) or we can have both
dedicated messages and message parameters (e.g., priority parameter in
a connection-start message). Note that dedicated messages are required
because sometimes you want to change the state in the middle of a
"process" (e.g., change priority or default services of an existing
connection).

Should we clean the current mess and rely exclusively on dedicated
messages? Their overhead is small and this approach will keep the
protocol cleaner and implementations a bit simpler. What do you think?

- connection-end

Section 7.2 writes "senders: OPES processor only". That's wrong
isn't it. It should read: "senders: both OPES processor and callout
server". What about adding an optional error parameter here too?
There are a few places where OCP forces to send connection-end and
closing of the connection in case of an error. That parameter could
help to debug which error has been detected.

Will fix/add.

- connection-services
Is missing an abbreviation in section 7.4

Will add.

- xaction-start

I always stumble on the optional services parameter. I am not yet
convinced that we need this on a transaction basis. I think we had
this discussion already; need to look up the old thread again.

And see above. We need to be consistent. The current approach is not.
Connection, transaction, and application message determine "scope".
Some state changes may need to be scoped (e.g., services applied to
this transaction should not affect other transactions on the same
connection).

- meta-as-is
We have data-have and data-as-is.
We now also have meta-have but no meta-as-is. Needed?

Probably yes, for consistency reasons. We should let implementations
to use identical mechanisms (i.e., the same code) to exchange data and
metadata.

- data-as-is
The description still talks about copy-am-id which is not longer defined

Will fix.

- ABNF glitches
I am not an ABNF expert but I think that
 -there should be no brackets in the bare-value definition
   bare-value = 1*safe-OCTET

Will fix (all occurrences).

 -the definition of size is not correct because since CR can be
 defined as %d13, the range %d0-2147483647 is not the ASCII decimal
 value representation

Hmm... You are right, but I am not sure what the correct fix is. I
cannot understand whether writing just 0-2147483647 is allowed in
ABNF. BEEP uses that, but I cannot see anything in RFC 2234 that would
make such a range a valid ABNF terminal. We can use 1*DIGIT instead
and add more restricting prose. Does anybody know what the right thing
to do is?

 -we should make sure that linear white spaces are not allowed in
 between some elements (not sure whether this is automatically
 given)

The following text has been accidently removed from the spec:

     There are no "implied spaces" common to MIME-based grammars. The
     syntax is restricted to spaces allowed by the above BNF.

Will polish and add.


Thanks a lot,

Alex.