[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
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.