On Wed, 20 Oct 1999, Robert Webber wrote:
> At 10:40 PM 10/19/1999 +0000, Kriss Andsten wrote:
> ...
> >Some way of negotiating the data would be spiffy, speaking of bloat.. if
> >the client side feels like sending its local timestamps in binary, or
> >'negotiate away' some field or functionality, that certainly wouldnt
> >-hurt-.. ...
>
> Except for the bloat, of course... 8:] If the fields are labelled it is
> possible to unilaterally send fields which otherwise have to have their
> content and syntax negotiated. Negotiated feature sets often seem to send
> their designers and implementers to a world of pain (a.k.a. Geneva,
> Switzerland). If you can negotiate options, can you negotiate that you
> want one set if some particular option is available and another if it
> isn't? Express preferences for options? Who gets to decide which set of
> options is actually used? Can it be asymmetric?
In the simplest form, the recieving end could tell the sending end what it
wants. It's then up to the sending end to honour this - or blatantly
ignore it. The recieving end would have to be prepared to accept any junk
sent at it of course, but if both sides of the communication supports such
CAN or SHOULD features, it wouldnt hurt..
Labelled fields, yes..
\001 = timestamp, \002 = message, \003 = hash.. Field type, plus length of
field, would make a good base for non-painful negotiation. Some rulesets
could be sent by the reciever, if the sender doesnt support them, or does
not feel like processing more than say, three max, it just doesnt process
the others. Either way, the reciever MUST BE prepared to accept all fields
that show up..
Cant quite see how this makes things messier than it has to be if it's
ignorable by the sender :)
> All these things can be useful, but we're at an awful early stage of
> development to be signing up for a lot of complexity
Complexity, no, but it's better to have some brainstorming (list now) and
come up with a general idea and polish than one later on, than come up
with a "$timestamp $string\n"; protocol and extend that one later on,
imo..
> bob
Kriss
--- .... --..-- -.-- --- ..- .-. . .- -.. -- --- .-. ... . --..-- . .... ..--..
Kriss Andsten <[EMAIL PROTECTED]> telnet slartibartfast.vogon.se 4243
