Subject: [Ietf-not43] transaction settlement issue stated in Appendix B.

From: [email-masked] (Andrew Newton)
Date: Mon, 10 Feb 2003 14:51:25 -0500

From Appendix B. of the new draft:

>       Query Distribution and Non-generic Query Referrals - The working
>       group has discussed issues surrounding query referrals and their
>       impact on certain classes of servers in a query referral mesh.
>       Proposals have been suggested for a robust referral mechanism and
>       a separate transaction token-passing system to provide a means to
>       solving this class of problems.

Given the lack of response on this issue and going by the notes from the 
last meeting in this area, here's my attempt to tackle this one:

Query Relay Bag

When issuing a referral, the protocol MUST be capable of supplying a
relay bag from the server to the client, and the protocol MUST be
capable of allowing the client to submit this relay bag with a query
to the referred server.  The use of the relay bag MUST be OPTIONAL.
The protocol MUST NOT make any assumptions regarding the contents of
the relay bag, but the relay bag MUST be described using the
schema language of the protocol.

-andy

---

From: [email-masked] (Andrew Newton)
Date: Tue, 11 Feb 2003 14:12:56 -0500

> schema language of the protocol.

It has been brought to my attention that this definition needs 
explanation.  I'm sorry for not doing so.  Specifically, the term "bag" 
is not used generically enough in the computing industry for its meaning 
to be universally understood.

 From m-w.com:
> a usually flexible container that may be closed for holding, storing, or carrying something

I didn't want to use the word "blob" as it tends to have specific 
meanings to certain database people and one of the b's is often 
interpretted as "binary".  I also didn't want to use the word "token" as 
that also has a separate meaning when it comes to text parsing.

So perhaps the explanation that might go under "service description":

In some models where service coordination among participating
server operators is utilized, there might be needs to allow a
referring server to pass operator-to-operator coordination
data along with the referral to the referant server.  Such needs
might be auditing or tracking.  This feature requirement
allows a server to pass to the client a flexible container
of unspecified data ("bag") that the client should pass to the
referant server.  The bag has no meaning to the client.

-andy

---

From: [email-masked] (Leslie Daigle)
Date: Sun, 16 Feb 2003 15:13:45 -0500

I think the revised text is much clearer.

I also think the expected behaviour should be spelled out,
e.g., for what happens if the bag has unknown or undesirable
contents.

In terms of requirements, that might be something like:

  A service MUST accept and process the query with a bag;  
  refuse the query with an error message if it does 
  not recognize the data in the bag;  or refuse the query
  with a different error message if the data in the bag
  is of the proper format but is otherwise unacceptable
  (e.g., out of date tokens, or general refusal to handle
  referred queries at this time).

  The protocol MUST provide different error messages to
  indicate whether the bag is of unrecognized format
  (permanent failure), if it contains unacceptable
  data (permanent failure), or if it contains data
  that means processing is refused at this time (transient
  failure).

Note that it would be possible to specify that the
server could issue a warning message and then process
the query as if it were not a referral (unbagged).
However, I suspect that adds a level of complexity
for little return -- in practice, clients will ignore
the warning message and assume the query was successfully
executed while possibly producing unexpected results.

I think it's also important to make  it clear that there
will be no more than one bag per referral.  If the referrant
server generates another referral itself, it must supply a new
bag (and it doesn't matter whether that's the same as
the old, cumulative, or entirely new).

And, 

> referant server.  The bag has no meaning to the client.

additionally,

 "The client {MUST | SHOULD | MAY} pass the bag as part of any 
  query made to a referrant server as a result of this referreral."

I'm not sure which of MUST, SHOULD or MAY it should be.
This proposal came up in the context of handling adjustments between
servers in the cases of referrals.   In that case, if the
client passes the bag, it's plainly acting on a referral
(with whatever increments or decrements of quality of service,
willingness to play, and costs that might entail).  But,
there's truly nothing stopping the client from making the
query *without* the bag, and having it look like a completely
new query at the referrant server.   I.e., it's pretty hard
to enforce a "MUST"; it will be effectively a "MAY" in practice.

What I think that means is that the requirement should say
"MUST", and that service operators will pragmaticaly have to
handle life as if it's a "MAY".  That is, assert that the client
MUST pass the bag, and if you're trying to restrict the amount
of referral traffic you serve, use some *other* way to identify
"local" (direct) queries, and don't answer any non-local queries
that don't have bags.

With all that mental meandering done, I think it means the
CRISP requirement text is:

  The client MUST pass the bag as part of any query made 
  to a referrant server as a result of this referreral.

Leslie.

-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat 

Leslie Daigle
[email-masked]
-------------------------------------------------------------------

---

From: [email-masked] (Andrew Newton)
Date: Wed, 19 Feb 2003 12:09:46 -0500

Leslie Daigle wrote:
> 
>  A service MUST accept and process the query with a bag;   refuse the 
> query with an error message if it does  not recognize the data in the 
> bag;  or refuse the query

I'm not sure this is needed, especially given that service requirements
are not longer MUST/SHOULD issues.

>  that means processing is refused at this time (transient

However, from a protocol standpoint, this makes sense to me.

> the old, cumulative, or entirely new).

Also a good point.

> "The client {MUST | SHOULD | MAY} pass the bag as part of any  query 
> made to a referrant server as a result of this referreral."
> 
[...SNIP...]
>  The client MUST pass the bag as part of any query made  to a referrant 
> server as a result of this referreral.

You had me at "additionally".

-andy

---

From: [email-masked] (Leslie Daigle)
Date: Thu, 20 Feb 2003 18:12:14 -0500

> are not longer MUST/SHOULD issues.

I respect the WG's consensus that it shouldn't
be defining policy for the service (by making requirements
on server behaviour), and my concern is just that we
shouldn't specify a protocol and then imply that the
spec needn't be followed (in terms of the semantics).

I think that concern would be addressed by including
a sentence or two, where you distinguish between service
description and protocol requirements, saying that <while
individual servers/service operators may not support all
features that the protocol can support, they must
respect the semantics of the protocol queries and
responses>.  Except, written in English, not this tortuous
phrasing :-)

In other words, you shouldn't return referrals if you
don't mean it, etc.

Leslie.

--

---

From: [email-masked] (Andrew Newton)
Date: Thu, 20 Feb 2003 18:41:37 -0500

> responses>.  Except, written in English, not this tortuous

This sounds like a good idea to me.  Perhaps that has been something 
that has been lost in all this.

> In other words, you shouldn't return referrals if you

And what a fine example... perhaps it should turn up in the draft.

-andy