> 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?
>> The parameter message= is added with a quoted string value to allow
>> other parameters on the same result line when an error reason/message is
>> sent back.
>>
>> The parameter user= is added to hold the username whenever relevant for
>> any reply.
>>
>> Other parameters are on the planning board for addition after the
>> changes. So far I have: ttl= for setting a desired credentials-TTL,
>> group= for associating a group name with the user=, tag= extended from
>> external ACL to auth.
>>
>>
>> Opinions? problems? other ideas?
>
> I do not know much about existing helpers, but I would recommend using
> the same set of basic syntax rules for _all_ messages:
>
> <responsecodeterminatedbywhitespace> [name=value]*
> where the value syntax is as discussed above. This approach would make
> writing a general response-buffer-to-response-structure parser easy and
> simplify addition of new fields or extensions.
I agree, with a proposed modification (pseudo-regex syntax):
<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.
-- /kinkieReceived on Mon Mar 14 2011 - 16:05:42 MDT
This archive was generated by hypermail 2.2.0 : Mon Mar 14 2011 - 12:00:04 MDT