attribute exchange value encoding

[Johnny Bufu]

On 29-May-07, at 2:33 AM, Claus Färber wrote:

> Johnny Bufu schrieb:
>> The attribute metadata can be used to define attribute-specific
>> encodings, which should deal with issues like this.
>
> Ah, so the _usual_ way is that the metadata (Can this be renamed to
> "datatype definition"? "metadata" is very misleading.) defines the
> encoding.

That would be the preferred way, yes. "Metadata" seems to make sense  
to most people involved in the schema effort, because it can contain  
other stuff beside data type description. But this is a work in  
progress, so if you're interested and want to make your case I'm sure  
you'll be most welcome on the idschema list:

	idschemas at idcommons.net
	http://mail.idcommons.net/cgi-bin/mailman/listinfo/idschemas

> For binary data, it will be base64Binary or hexBinary as
> defined in XML schema. Correct?

Yes, whatever encoding is defined in the metadata document.

>> The AX protocol has to stay simple (that was overwhelming feedback
>> I've received at IIW). The base64 encoding is there as a convenience:
>> if a number of OPs and RPs agree on an attribute type (the classical
>> example being an avatar image) but don't want to go to the trouble of
>> publishing metadata information,
>
> In other words: The metadata is implicitly agreed upon by the parties
> involved. If they can agree on the meaning and the base format  
> (integer,
> string, *binary,...) they can also agree on an encoding (e.g. agree on
> base64Binary instead of *binary).
>
> So I don't think AX needs means to flag base64 data. The parties
> involved should know when base64Binary or hexBinary is used by out of
> band information (metadata/datatype definition or mutual agreement).

I see your point - if the parties involved agree on the attribute  
type and (implicitly) on its data format, they can / should go one  
step further and agree on the encoding as well. And eventually the  
prevailing method would be to programatically determine the encoding  
from the metadata documents.

> In other words, AX should just restrict values to UTF-8 strings and
> recommend base64Binary (or hexBinary) for datatypes (datatypes, not
> data!) that can't be represented as UTF-8 strings.

Yes, that would work too; it would be basically AX draft-5 plus  
disallowing newlines in attribute values in order to comply with the  
underlying OpenID data formats.

If there's agreement that encoding is more tightly coupled with the  
attribute types and their metadata definition, we can just reference  
that in the AX spec.


Johnny