Attribute Exchange pre-draft 5

Dick Hardt dick at sxip.com
Mon Apr 2 22:26:20 UTC 2007


On 2-Apr-07, at 2:41 PM, Rowan Kerr wrote:

> On 2-Apr-07, at 5:27 PM, Josh Hoyt wrote:
>> I'm thinking about differentiating between an attribute that's not
>> available and an attribute that *is* available, but its value is "".
>> I. e. difference between a null pointer, and a pointer to an empty
>> string.
>
> That was part of why I had the idea of adding one or two extra
> response values... to know whether a user released the attribute
> (and whether it was supported by the OP).

Personally, I don't see that much value to the RP in the RP getting  
additional information that the data was available but not released,  
and unnecessary disclosure on behalf of the user.

>
> By looking at the namespace RDFs for the OP as you suggested,
> the RP should be able to decide whether the value is supported
> by the OP, then if it's blank AND supported, then the only thing
> the RP can't be sure about is whether or not the user released it.

Note that AX enables an OP to dynamically support new attributes on  
the fly -- and publishing ALL available attributes for a user would  
be a privacy problem.

>
> If the RP really needs a value, they can prompt the user for
> it after getting the AX response and it doesn't really matter
> whether the OP supports it or not. (Unless you're going to
> maybe try and Store it back to the OP later on).
>
> But prompting users twice for the same value (for lack of any
> way to know the cause of a blank value) might be an annoying
> experience.

The RP has given the OP a hint that the value is required. If the  
user has instructed their OP to NOT give the value, then the RP can  
then decide what to do, and the user will likely expect to get  
prompted again.





More information about the specs mailing list