[BXXPwg] Draft Minutes of last week's meeting
Mon, 14 Aug 2000 11:28:26 -0700
> Yes, a CDATA block could be convenient there. The important aspect of
> my proposal is that the content model of <start>/<profile> be
> <!ELEMENT profile (#PCDATA)>
the problem is that PCDATA doesn't allow all possible values for each octet.
you can not use XML to contain *arbitrary* binary data unless you first
encode that data. that's why the SASL family of profiles use the <blob>
element to encode part of their payload.
so, this gives us a choice: we can either base64 encode everything
(including nested XML), we can have two methods, one for nested XML and the
other for everything else, or we can require that each profile explain how
it encodes initialization data. all of these are consistent with defining
the content model for the <profile> element as processed characters.
> You commented that you think the idea is cool. Does it take anything
> away from your original intention? I wouldn't want to cripple
> something essential in BXXP that I haven't seen. This proposal does
> make the channel start/accept API easier to craft.
it is certainly a change to the way things work now. it doesn't change my
burden of implementation, though it might make your's easier. i guess i can
live with it.
> The weirdness around submitting several candidate profiles for a
> channel, then trying to figure out which one got accepted, remains. Do
> you have any ideas on that one?
err, what wierdness? it's a negotiation: you specify N>=1, and the other
side tells you which one it picked (or gives you back an error).