[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Equiv of single-line value verses a multiline value with one line

Let me rephrase the question, since I now realize the matter of what
exactly the implementation does is beside the point.

Are protocol specifications allowed to distinguish between
>    #$#...  kwd: "foo"
> and
>    #$#...  kwd*: "" _data-tag: 666
>    #$#* 666 kwd: foo
>    #$#: 666

By "distinguish" here I mean not whether the values are transmitted
differently but rather that the "end uses" of the values by the protocol
are different (i.e., the client does NOT end up converting "foo" to
{"foo"} or {"foo"} to "foo" somewhere along the way, AND this is not
something like the old .description property where "foo" and {"foo"}
ultimately mean the same thing)?

Do there currently exist protocols that draw such a distinction?  (if
so, we're forced into choice (C) below, or we have to eradicate all uses
of such protocols).

Note that a "no" answer to the first question still allows for both of
the following possibilities
(1)  MCP implementation translates both identically
(2)  MCP implementation translates them differently, 
     say to "foo" and {"foo"}, but then MCP clients are required
     (as per the individual protocol spec) to treat "foo" and
     {"foo"} identically.

Possibly included in this is the requirement that nothing bad happen if
a receiver who is expecting a kwd: receives a 1-line kwd:* instead.

(1) makes life slightly more annoying for MCP implementers, (2) makes
life slightly more annoying for protocol implementers.

(A)  Definitive NO.  
     Protocols that draw such a distinction are outlawed.  
     kwd: and 1-line kwd:* must always have the same effect.
(B)  Half-assed NO.  
     kwd: and 1-line kwd*: must have the same effect 
     whenever a protocol allows both.  Thus, e.g., 
     it remains legal for an implementation to barf (ignore 
     a message) when protocol only mentions the possibility
     of sending kwd: and some idiot sends a 1-line kwd:* instead. 
(C)  YES (default)
     Anybody is free to design a protocol that 
     treats kwd: and 1-line kwd:* differently
     (even if none yet exist)

If either (A) or (B) is to be the case, this must be made explicit.
(B) is arguably the least work for implementers.
(C) is arguably the least work for implementers other from John :)

Both (B) and (C) require that string escapes be able to represent