On 3/26/07, Johnny Bufu [EMAIL PROTECTED] wrote:
Since draft_4 [1] we've done some implementation and testing (as well
as listened to community's suggestions on related issues), and have
incorporated some changes into a pre-draft-5. Before publishing it I
would like to see your comments about
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:
On 2-Apr-07, at 3:16 PM, Josh Hoyt wrote:
What about attributes whose value could reasonably be an empty string?
It would be reasonable to answer don't do that, I'm just curious how
you expect this case to be handled.
I'd say it's up to the RP to decide whether the data returned is
valid
On 2-Apr-07, at 3:14 PM, Josh Hoyt wrote:
On 3/26/07, Johnny Bufu [EMAIL PROTECTED] wrote:
One feature we didn't figure out yet if its benefits would be worth
the added complexity:
- in a fetch response, distinguish between attributes
that the user didn't *want* to release
On 4/2/07, Rowan Kerr [EMAIL PROTECTED] wrote:
On 2-Apr-07, at 3:16 PM, Josh Hoyt wrote:
What about attributes whose value could reasonably be an empty string?
It would be reasonable to answer don't do that, I'm just curious how
you expect this case to be handled.
I'd say it's up to the
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
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
On 2-Apr-07, at 12:10 PM, Josh Hoyt wrote:
On 3/26/07, Johnny Bufu [EMAIL PROTECTED] wrote:
- Added ax.mode parameters to all messages, to unambiguously identify
the message types; the values are:
fetch_request
fetch_response
store_request
In a user-centric model, what's the difference? (Seriously)
On Apr 2, 2007, at 12:14, Josh Hoyt wrote:
On 3/26/07, Johnny Bufu [EMAIL PROTECTED] wrote:
One feature we didn't figure out yet if its benefits would be worth
the added complexity:
- in a fetch response, distinguish between
