[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

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.