encoding newlines in attribute values
Dick Hardt
dick at sxip.com
Fri Apr 20 18:18:37 UTC 2007
On 20-Apr-07, at 11:05 AM, Douglas Otis wrote:
>
> On Apr 20, 2007, at 10:56 AM, Johnny Bufu wrote:
>
>>
>> On Apr 19, 2007, at 10:46 AM, Josh Hoyt wrote:
>>> Each attribute already has to define its encoding rules and data-
>>> type. The mechanism for encoding a newline can be part of this
>>> encoding, if newlines are allowed in the value. Once there is one
>>> attribute that has a defined encoding for newline, when new
>>> attributes are defined, they can re-use this encoding. Does that
>>> sound reasonable?
>>
>> So are you proposing that AX only accepts strings without newline
>> characters in them, and the encoding to such a string should be
>> handled by the parties who actually consume the attributes, according
>> to the type / metadata specs?
>>
>> This would be nice and simple for the AX itself, however it would
>> require everyone defining attributes to also define a 'encoding to
>> strings without newlines' for them.
>
> The use of base64 can be confined to individual elements within an
> attribute where newlines are _not_ affected. There should be a
> standardized template for declaring base64 encoding starts with 'X'
> and ends with 'Y';
Great idea Douglas.
To expand on that and include Mark Wahl's proposal about locale
encoding[1] in a standard way for attributes so that the libraries
can do the right thing 99% of the time.
I would propose that AX data have a default encoding that can be
overrode by the attribute metadata. The default would be:
URL encoding for text data
escape sequence for locale using mechanism in RFC 3866
escape sequence to indicate binary data that is then base64 encoded
[1] I see that Mark's proposal is not up on the site yet. It is a
good proposal though!
More information about the specs
mailing list