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

*Discussion* re: multiline (tagged) data



> First, I would note that the old way of doing things leaves out authkeys on 
> continuation and end lines; perhaps this was discussed before I joined 
> the list, but it seems like an important omission.  Somewhat more 

this is deliberate, and covered in the spec:
[...]
<LI>The value supplied in the <SAMP>_data_tag</SAMP> argument is used
in place of the authentication key.
[...]
<P>Multiline values lack authentication keys; the data tags are
roughly as secure as the authentication key argument on regular
MCP messages (that is, not very), and their lifetime is only the
length of a multiline message.  For this reason, however,
implementations should use some care in the choice of multiline value
data tags, and should ignore messages for which no matching
<SAMP>_data_tag</SAMP> argument has been seen.</P>

> generally, there is no way in the current spec to pass additional 
> data (key/value pairs or otherwise) on continuation lines.  So I propose 
> that additional data be allowed between the continued tag; that is, in 
> the current spec's form
> 

this is also deliberate; the idea here is that you can directly throw
everything after the tag into the value without doing any parsing.
there's actually a fairly good, though not particularly obvious,
reason for this: when editing code, a lot of reserved characters are
gonna pop up.  rather than having to quote every line (which, i admit,
isn't much of a problem, but still) you can just dump the data
straight into the value.

 > #$#multline-data-follows foo* = datatag bar* = datatag
 > (here datatag is the tag for the entire line)
 > 
 > while if you favor the second (value continuation) it would be
 > 
 > #$#multiline-data-follows foo* = datatag1 bar* = datatag2
 > (here datatag1 and datatag2 refer to different values)
 > 
 > In this way, each philosophy may be accomodated by a single kind of start 
 > line.

yowch.  to a certain extent i see the simplicity of this approach.
but i'm just not sure how i feel about it.  it seems to make the
entire system somewhat more difficult to comprehend.  in the end, i'd
like to come down on the side of a simple rule for data and end tags.
				dk