On 03/14/2011 11:15 AM, Kinkie wrote:
> On Mon, Mar 14, 2011 at 5:46 PM, Alex Rousskov
> <rousskov_at_measurement-factory.com> 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.
A simple solution that is kind of symmetric and offers the advantages of
both prefix and suffix approaches is to replace '=' with the encoding
info, if any:
name = rawvalueterminatedbywhitespace
name encoding encodedvalue
Since '=' can be treated as the "identity" coding, we have:
name encoding encodedvalue
Cheers,
Alex.
Received on Mon Mar 14 2011 - 18:46:54 MDT
This archive was generated by hypermail 2.2.0 : Tue Mar 15 2011 - 12:00:03 MDT