On 3-Apr-07, at 3:32 AM, Josh Hoyt wrote: > If I understand correctly, the response to a request for an attribute > with "count.x=1" is different from the response for a request with no > count specified, even though the meaning is the same. > > (namespacing left off for clarity) > > Request: > > .type.a=http://example.com/a > .count.a=1 > .type.b=http://example.com/b > > Response: > > .type.a=http://example.com/a > .count.a=1 > .value.a.1=avalue > .type.b=http://example.com/b > .value.b=bvalue > > Even though the request for a and b have equivalent meaning (send zero > or one values for this attribute) the response MUST encode them in > different ways. I think this is ugly, because the detail of the way > that the attribute was requested has to be preserved in the code, to > ensure that the response can be encoded correctly. (it's not > sufficient to just default the count to one if it's not specified)
> > Is there a reason that it's specified this way? I'd prefer if there > was only one way to do it. Good point. Either .count. has to be more then 1 in a request so that there is only one way to do it, or the response could be in either form where .count.=1 to be consistent with the request being able to be in either form. > > Also, can the count be zero in the response? it seems like that's OK, > and if it is, it'd address my concern about overloading zero-length > strings to mean "no value." Another good point. I agree it should be able to be zero. -- Dick _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs