[PROPOSAL] standard multivalue parameter mechanism

[Dick Hardt]

The advantage of defining it in the spec is that there is a standard  
way of doing multivalue, rather then multiple multivalue methods. ;-)
Fine with multivalue being an attribute of the parameter. How about  
we add a paragraph in section 5:

Multivalue Parameters

Some parameters may contain multiple values. Any parameter declared  
as mulitvalue will use a comma to separate the values, and if a  
string contains a comma, then xxx will escape it

(looking for suggestions from implementors here!)


On 1-Oct-06, at 3:18 AM, Recordon, David wrote:

> The only concern I see with this is that an association handle may  
> contain commas.
> > Associations are referred to by a handle, which MUST be a string
> > 255 characters or less, and consist only of ASCII characters in
> > the range 33-126 inclusive (printable non-whitespace characters).
>
> Is there a reason to have the authentication spec itself define  
> this?  Could it define it only for the required field(s) and then  
> where it discusses that multiple keys with the same name are not  
> allowed, it also recommend that extensions use a comma as a  
> delimiter when needed?
>
> --David
>
> -----Original Message-----
> From: specs-bounces at openid.net on behalf of Dick Hardt
> Sent: Sat 9/30/2006 4:45 PM
> To: specs at openid.net
> Subject: [PROPOSAL] standard multivalue parameter mechanism
>
> Motivating Use Case
> ----------------------------
> Passing multiple values for the same parameter, or lists is useful
> for the protocol. Having a standard way of doing it will make it
> easier for implementors and less prone to error. openid.signed takes
> a list, and openid.ax.required and openid.ax.if_available apply to
> zero or more items.
>
> Given that multiple parameters is not desired due to 1) the
> enumerated list for what was signed cannot have multiple values, and
> 2) a number of web application platforms are allergic to multiple
> parameters of the same name, putting multiple values in the same
> parameter separated by a delimiter is the other obvious option.
>
> Proposed Implementation
> -----------------------------------
> Given that the comma "," is already being used as a delimiter for
> openid.signed, that a comma be considered the delimiter for any
> OpenID parameter.
>
> The comma would then be an escape character in all OpenID strings,
> and that if a comma is in a string, that it is escaped out with
> another comma as such ",," ie. the string "Apt. 123, 55 Sesame St."
> would be "Apt. 123, 55 Sesame St."
>
> ... suggestions for other delimiting mechanisms welcome!
>
> -- Dick
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
>
>
>