[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: official release
Date: Wed, 26 Nov 1997 12:12:50 -0500
X-UIDL: 880564833.000
From: "Jay A. Carlson" <nop@kagoona.mitre.org>
Sender: owner-mcp-dev@research.att.com
There is one remaining major issue, from my point of view, which I've
brought up a few times but don't recall getting a real response on:
Can we *please* quote the values associated with multiline bodies?
We can unify parts of the BNF and reuse the single-line parsing
implementation. Aside from the usual excuses of concept reuse and
coherence this also means the MOO implementation can (as usual) just
use the MOO tokenizer. The overhead of the additional slashification
for quotes and backslashes is pretty small and we know that any MCP
implementation already has this functionality available.
Why cant this be done in the "splitter" part of an MCP
implementation, if it so desires? Why does this have to be in the
spec?
My reason for not doing this -- concept reuse and coherence is
pretty weak in this context -- is that the <value> might be
coming from some random process that doesnt care diddly about
slashification. Why introduce slashification on the way out, so
that *every* receiver has to deslashify to reconsitute the
initial <value>, when instead a receiver that wanted to see a
slashified value could do so trivially (through the splitter)?
I of course vote yes on the mcp-cord and mcp version: changes as any
right-thinking individual would.
I was going to make some remark about how it would be cool if by
private agreement clients and servers could support multiple auth
keys to model different levels of trust (such as blessed-by-server-adm
ins and something-Networker-did) but I realized that there's really
no point in including this in the spec at this point, especially
given authkey checking is worded as a "should" now anyway.