Attribute Exchange draft 5

[Johnny Bufu]

Thanks everyone for the good feedback and discussions during the last  
week. I went through the messages and added clarifications and  
modifications for the issues where there seemed to be consensus.

Since there were a handful of changes, I've tagged the result and  
asked David to put draft 5 up on openid.net, so we can use it as a  
base for sorting out the remaining issues. You can see AX draft 5 here:

	http://openid.net/specs/openid-attribute-exchange-1_0-05.html


The outstanding issues so far (and today's change log) are summarized  
below. Please voice your opinion about them! (Separate threads for  
each discussion would help with tracking.)

If I've missed anything or there are new issues and feedback please  
bring that up, too.


======================================================================

How does the RP request all the values available at the OP for an  
attribute?
Options:
	magic count value = -1?
	others?


The OpenID realm has no meaning in a store request; need to be  
clarified? Suggestions?


Todo: Example for the SReg to AX upgrade path.


Newlines are not allowed in openid field values; how do we deal with  
newlines in attribute values?


How can the RP determine the maximum value length that an OP will  
support for a particular attribute?


What is the maximum length of an alias string that an RP can expect  
an OP to support?


How does the RP determine the schema of the provider to know what to  
ask for?


OP is not required maintain preserve the order of the attribute  
values internally and in a fetch responses; does it needs  
clarification in the spec?


Is it legal for the values of a multi-valued attribute to be bytewise  
identical (.fav_movie.1=X, .fav_movie.2=X)?


How can the RP determine the maximum value count that an OP will  
support?


What is the locale of the status messages in the protocol?

======================================================================

CHANGELOG:

Removed OpenID error responses reference - AX doesn't actually use them.

Added clarification note about OPs dereferencing the attribute URIs  
in order to dynamically assist users.
Mark Wahl's issue #2: http://openid.net/pipermail/specs/2007-April/ 
001565.html

Refactored required / if_available description to use the same  
phrases; dropped mention of 'error condition'.

Modified count and blank attribute values:
- OP may return less than the number of requested attributes
- OP must not return a .value. field if a value was not provided
- count=0 is allowed to explicitly state that no value was provided  
for an attribute
- for count=1 both response formats (with or without count) are allowed
http://openid.net/pipermail/specs/2007-April/001430.html
http://openid.net/pipermail/specs/2007-April/001469.html

update_url in fetch requests:
- consequent updates use the OpenID protocol
- must match the realm in the OpenID message
- use of 404 for unsubscribing

Clarified the intent / usage of store requests.

More store requests clarifications:
- error message intended to be presented to the user
- alias used to associate values with type URIs within the message
- rearange the intro paragraphs

Disallowing periods in attribute aliases.

======================================================================


Thanks,
Johnny