Attribute Exchange 1.0 svn revision 295 review

[Dick Hardt]

On 5-Apr-07, at 4:48 PM, Josh Hoyt wrote:

> On Apr 5, 2007 at 8:41 AM, Dick Hardt <dick at sxip.com> wrote:
>> > There is no way to say "I want as many of X as you have, and I  
>> don't
>> > care how many that is"
>>
>> Good point. Perhaps have  a magic value like -1 to indicate as many
>> as the user will release?
>> I had thought the RP would likely have a maximum they would want in
>> most situations.
>
> Generally, yes, although when we were discussing the spec, we talked
> about using one pass of attribute exchange to get all of the available
> attributes and another pass to request the attributes themselves. When
> requesting the available attributes, it seems like you'd want to say
> "give me all the attributes that are available" instead of "give me up
> to 500 available attributes," but I could be wrong.
>
> It might be good to give a bound on the response size for every
> request, although in cases such as above, it might be useful to the
> relying party to know if there were values that overflowed the limit.
> It wouldn't be difficult to add a flag, but I'm also not sure whether
> it would be worth the extra complexity.

Our experience to date has been that we don't have multiple so far. I  
am sure there will be some use cases that do.

Good question if those will be limited or not. Our thinking had been  
that some applications may have 4 slots for attributes in the DB, so  
only would ask for up to 4 attributes.


>
>
>
>> > There is the issue that I brought up in a separate message where
>> > count=1 is different from not specifying a count, even though they
>> > both mean 1 or 0 values.
>>
>> The perl way would be to have "more then one way to do it" and allow
>> both methods to mean the same thing.
>>
>> The python way would be "there is one way to do it" and not allow
>> count=1 in a request
>
> Well, clearly it's better to have one way to do it. But seriously, the
> main problem that I have with it is that the specification prescribes
> the response format based on the request format. That is, my code has
> to keep track of whether the request used count=1 or just didn't
> specify a count, instead of just recording that the request asked for
> one value, so that the later code can know how to encode the value. If
> there's really more than one way to do it, you should be allowed to do
> it either way.

I agreed with you previously that the response being able to work  
either way if the request can. Sorry if that was not clear.

>
> I'm guessing that you made that restriction on the response format so
> that relying parties can know what the form of the response will be.
> Is that correct?

It was on the grounds that this is what the RP had requested, so the  
OP should do the same. But I agree with you that allowing either is  
preferred, and am also ok with there only being one way of asking for  
a single value. No strong opinion here on that.

> Another restriction on the response message is that you have to send
> responses even if they are empty. Can you give the rationale for
> requiring the fields with no values to be sent?

I am unclear on what your question is. Would you clarify?

-- Dick