attribute exchange value encoding

[Johnny Bufu]

Hi Drummond,

On 25-May-07, at 8:55 PM, Drummond Reed wrote:
>> One remaining question is about the choice of encoding for strings.
>> Percent-encoding (RFC3968) seems the simplest from a spec
>> perspective, however some libraries provide (better) support for the
>> older URL-encoding (RFC1738), which throws '+' characters into the
>> mix. Which do you think would work best for implementers, users, and
>> would cause less interop problems?
>
> FWIW, encoding "+" can be a hassle as it's a legal character in  
> media type
> values and is also sometimes used for spaces. I'd vote for pure  
> RFC3986
> percent-encoding.

Simplicity was the reason for requiring percent-encoding for only two  
characters.

Then it was brought to my attention that implementers may be tempted  
to use the more readily-available functions for URL-encoding, which  
do share the percent-encoding part with what's specified currently in  
AX, but will break other characters.

This is why I wanted to know what others thought about this being a  
potential problem.


Another option would be to define an equally simple but not-so- 
popular encoding, so that implementers are forced to write the  
required 5-line encoding routines themselves; but the unfamiliarity  
of it would add to the (perceived?) complexity of the spec.

I'm trying to find a good balance between simplicity, providing  
enough features, and avoiding deployment problems; so all feedback is  
highly appreciated!


Thanks,
Johnny