Re: reserved requests, cord message names

[Dave Kormann <davek@research.att.com>]

Erik Ostrom writes:
> I think if you're concerned about quoting issues, you can just send it 
> unquoted--like, REALLY unquoted, like, no #$#anything.  The idea of the 
> #$#text-line (or whatever) message, as I see it, is primarily for
> the sake of client internals.

(this came up in RL discussion with erik; here's what, roughly, we
came up with):
if what you're after is a chunk of the namespace _guaranteed_ to be
unassigned so that, if you choose to use it as a prefix to route
messages through your parser, you won't step on anybody else, you
should use the dns- namespace.  that is, the right way to guarantee
you can use a text-line message to route things through your parser as
john suggested is to use something like:

#$#dns-org-mitre-x-text-line text: ...

where the folks at mitre.org are presumed here to have decided that
the "x" namespace under their dns namespace is guaranteed not to be
assigned to any protocols.  since the dns portion is guaranteed to be
used only by the folks at mitre, you can guarantee this won't stomp
anybody.

of course, if what you're after is to use text-line to GUARANTEE that
a message is indistinguishable by all implementations from an in-band
message without leaving the context of the parser, i still say you
just really want to use a real in-band message and assume the parser
will do the right thing (and design _your_ parser to do the right
thing.)

ugh, i know that's unreadable.  if you stare at it long enough, it
might come into focus what i'm after.

[...]
 >> another, smaller issue: it's been a while; does anyone seriously
 >> object to my prefixing the #$#cord* messages with mcp- ?
 > 
 > Why?  It's just another protocol, isn't it?

yes; which means it needs to be in an appropriate namespace.  the spec
deliberately and explicitly reserves the entire non-dns/non-mcp
namespace for later assignment by some body of higher powers whose
identity is not yet known to mere humans.  the mcp- name hierarchy is
reserved for protocols "either required or recommended in this and
future versions of [MCP]".  the upshot of this is that the spec is put
in the odd position of restricting access to a huge chunk of the
namespace, and then immediately violating that restriction.
				dk