[BXXPwg] Draft Minutes of last week's meeting

Steve Harris sharris@primus.com
14 Aug 2000 11:57:09 -0700


"Marshall Rose" <mrose+mtr.netnews@dbc.mtview.ca.us> writes:

> 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.

Yes, I didn't mean to suggest that you would just pour any bytes you
wanted to in there. More, what I was suggesting is that you could have
something like a "geek code" string that fits within XML's definition
of a character, but isn't Base64-encoded. My assumption was that the
profile sender and receiver would be doing the encoding/decoding, so
the BXXP library wouldn't need to know whether or not to "decode" the
text before handing it over to the receiving profile (since it may not
be encoded anyway).


[...]

> 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).

I understand it at that level. My question is more about whether you
have any ideas about how an "open channel" function signature would
look. Right now, the best I can imagine is something with two relevant
return values: some designation of which profile got accepted, and a
handle to the newly-created channel. It's that two-return-value thing
that I'm calling "weird." It's "weird" when looked at from the API
side.

-- 
Steven E. Harris        :: sharris   @primus.com
Primus                  :: http://www.primus.com