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