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

Greg Hudson ghudson@MIT.EDU
Tue, 30 Oct 2001 09:31:21 -0500


I wrote:
> As far as the profile is concerned, the initialization element is a
> bucket of octets.  The profile gets to decide how they are
> interpreted.  See RFC 3080 section 2.2.2.

And of course, that doesn't make sense, since the initialization
element might not be base64-encoded, in which case it comes as
characters, not bytes.

So I think this really is ambiguous.  I still don't think adding a
text-encoding attribute is a valid answer for an implementation,
though.  A library could:

  * Pass the PCDATA of the initialization element back to the
    application (as characters), along with a flag saying whether
    encoding="base64" was specified.  Let the application figure out
    what to do with that.

  * Accept a character set specification to be used to decode
    base64-encoded initialization elements; for non-encoded elements,
    just return the PCDATA as characters.

Neither seems great.  But the point is, given that the BEEP
specification is ambiguous here, it is up to the profile to specify
what an encoded and non-encoded initialization element mean.