[BEEPwg] Trouble with TLS and transport mappings

Huston huston@franklin.ro
Fri, 30 Nov 2001 10:15:20 -0700


> 1) If backwards-compatibility is not a concern:
>
> Errata against RFC 3080: the 'encoding' attribute is depricated.
> Initialization messages as described in Section 2.3.1.2 are precisely
> BEEP Messages, as defined in Section 2.2. A
> "Content-Transfer-Encoding" may be specified to protect content.
>
> Additionally, the default "Content-Type" could be
> "application/beep+xml", which would maintain compatibility with
> existing beep+xml profiles (such as TLS and SASL profiles). (This
> would only add an additional newline to the head of the initialization
> message.)

If backwards-compatibility is not a concern, my vote is to make it
consistent with all other messages including the default "Content-Type".
This way beep libraries don't have to do anything special with the
piggyback'd data and to profiles the piggyback'd data will look just the
same as if it had been sent in the first MSG.

--Huston