[BEEPwg] Re: Underspecifications in RFC 3080? (profile content, SWS avoidance)

Chris Laas ctl@permabit.com
Tue, 30 Oct 2001 14:25:57 -0500

On Tue, Oct 30, 2001 at 02:18:31PM -0500, Jered Floyd wrote:
> > If the "encoding" attribute is "base64", then the content is simply a
> > chunk of octets; it may be assumed to have the MIME type
> > application/octet-stream if it's convenient.  Where is the ambiguity?
> This provides no opportunity for the character set of this
> base64-encoded initialization message to be specified, if it is to be
> interpreted as character data.  My impression of the BEEP spec is
> that, much as MIME content transfer encodings, the "encoding"
> attribute should be transparent to the application such that proxies
> along the way may translate between content-preserving encodings.

While it may have been your impression, it seems clear to me that the
spec says something entirely different.

> What you propose requires two distinct interfaces to an application
> using BEEP, one for encoding='none' which provides a character stream
> to the application, one for encoding='base64' which provides a byte
> stream with no associated metadata.  This is poor design.

Well, I would not claim that this is an example of good design.
However, I would claim that the spec is unambiguous, and that, as
specified, BEEP cannot allow this interface to be transparent to the
application.  If you wanted the interface you outline above, you'd
technically have to change the spec (as has been pointed out, it's
certainly an option).

On the other hand, the "require encoding=base64 contents to be
MIME-encoded" solution could easily be implemented as a thin layer
atop BEEP; it doesn't seem entirely odious to me that this feature
could be handled at the application layer.