On Mon, Mar 14, 2011 at 5:46 PM, Alex Rousskov <[email protected]> wrote: > On 03/14/2011 10:05 AM, Kinkie wrote: >>> You could handle encodings in the low-level value parser as well if you >>> make them explicit: >>> >>> name="string with some documented quoting rules" >>> name=base64:base64encodedvalue >>> name=rawvalueterminatedbythefirstwhitespace >>> >>> The latter assumes no raw value can start with "base64:". Other >>> quoting/encoding mechanisms are possible, of course. >> >> Why put that in the message, if we can do it in the label, and avoid >> all quoting issues altogether? > > Not sure what you mean by "label", but it is easier to write parsers and > extend functionality when parsers and packers do not rely on name > semantics to properly handle the message. > > If you meant moving value "base64:" prefix to the "name" suffix, that is > possible, of course, but keeping the encoding of the value closer to the > value itself is more "natural", and it would be a little easier to write > value encoders that way, IMO. I do agree that using name suffix will > help avoid encoding specs/value clashes
Yes, I used "label" in place of the "name" (see the example at the end of the previous mail: > <responsecodeterminatedbywhitespace> (name(:enc)?=value " ")* > > Where :enc, if specified may be ":b" (base64-encode), further codes to > be added as needed. As a separator we could use something different > from space to further reduce the risk of clashes. I agree that encoders may be easier, while using the name-based approach would IMVHO make decoders easier :) I tend to favour the latter as they generally carry more security risks, but I won't press the issue. Thanks, -- /kinkie
