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
_______________________________________________
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
