ietf-openproxy
[Top] [All Lists]

Re: OCP transport nomination

2003-04-24 14:14:30

[ speaking as the beep guy, and not the co-chair... ]

This looks pretty good.  The major performance issue is whether or not
the content message headers can be easily parsed without calling any
XML library.  The second issue is the same question for transaction
establishment.  The examples make it look quite easy.  It is imperative
that we be able to avoid calling XML libraries for these operations.

technical, "content message" headers are "mime things", not "xml things". you
can certainly write your own parser to handle the strict 1.0 version of xml that
beep uses for channel management, etc., if you're so inclined.


I'm not sure how much of an advantage BEEP's security mechanisms turn
out to be.  It doesn't seem to have any specific support for detailed
security policy, ...

nor would you want it to, given that security policies are
either domain-specific or are so general as to lack meaning.

the advantage is that you don't have to re-invent the wheel (since someone
already re-invented it for you). in other words, the wg doesn't have to argue
about how to encode tls negotiations, or sasl negotiations, etc. the wg doesn't
have to argue about the relationship between tls and sasl, etc.

a second advantage, is that you get to use the current practices developed by
the ietf's application area, without having to think about it. it is fair to say
that a great deal of the motivation behind beep was to give wg's the ability to
avoid thinking about the administrative aspects of protocol design.

/mtr

<Prev in Thread] Current Thread [Next in Thread>