discussion notes

[Erik Ostrom <eostrom@research.att.com>]

A few notes.  Dave and Ken and I discussed most of these a couple of
weeks ago, and I'd like to hear from other interested parties.

Cord IDs
========

The spec says that a cord ID, "when combined with the connection
endpoint which opened this cord, uniquely identified the cord;
however, since the connection endpoint will not be reflected in
messages sent on the cord, it is strongly suggested that
implementations take steps to ensure that the identifier provided is
globally unique."

1. What is "globally unique"?  I think this means "unique within a
given session".  Right?

2. I would do more than "strongly suggest" this; I think we should
require it.  I'd like the spec to eliminate the possibility of two
cords sharing an ID.

3. With this in mind, I'm not sure it makes sense to state that
implementations must ensure uniqueness, but not specify how.  The
problem is that without cooperation between client and server, neither
endpoint _can_ be certain that the other endpoint won't generate a
conflicting ID.  We could add a negotiation phase for declaring cord
ID prefixes; I'd prefer to just use "C" and "S" as standard prefixes
for the client and server, respectively (where client is the endpoint
that initiated the connection and specified the auth key).

4. The uniqueness requirement also means that each endpoint must
ensure that all cord IDs _it_ generates are unique.  The method for
doing this, of course, is up to the implementation.

Data tags
=========

Similarly, the spec should address head-on the possibility of
conflicting data tags.  In this case, tags don't need to be unique
across both endpoints; each message is sent in only one direction, so
even if both endpoints send a message with the same data tag at the
same time, they don't conflict.  We should probably specify only that
each sending endpoint is responsible for ensuring that it doesn't have
two messages with the same data tag in process at the same time.  That
is, if a message has been initiated with tag T, and has not been
concluded, it is not permissible to initiate another message with tag
T.

Note that this is not the same uniqueness requirement as that of cord
IDs, although any strategy that provides global uniqueness across a
session (a la cord IDs) will also ensure no simultaneous conflict (a
la data tags).

Whee.

BTW, although I was one of the people who argued for "tag field-name:"
in multiline fields, I'm beginning to regret it.

Messages
========

Under "Terms and concepts", the spec indicates that a message is a
single line.  Above, I've been using it to refer to an entity that may
contain multiple lines, such as

   #$#spam 12345 from: Biff text*: "" _data-tag: 9876
   #$#* 9876 text: This is some sample text.
   #$#END 9876 

If this isn't a "message", we should have a term for it.

Local editing
=============

The spec, as written, doesn't allow the sending of old-style multiline
messages, such as the local-editing messages that most MCP-enabled
muds use.  I think this is a good thing, but it means we need to fix
the edit protocol.  What we came up with was something like (did
anyone write this down?):

  S->C edit(name, location, type, text*)
  C->S edit-put(location, type, text*)

where 'name' is a human-readable description of the thing being
edited; location is used in the edit-put message to tell the server
where to store the text; text* is a multi-line field containing, uh,
the stuff to edit; and type is one of a small set of defined types.
(If we followed the lead of the MCP1 editing protocol, types would be
'text', 'string', 'value', or 'program'.  I don't think much of that,
but I want to stop typing now, so, I'll leave it open for discussion.)

That's all for now.
--Erik