> 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. -- /kinkie
