To amplify my previous reply on priority, priority is associated with
the I2RS Client. it does not change even if the client is acting on
behalf of multiple secondary identities. (If the use case requires that
variability, use multiple primary identities, with separate sessions.)
Thus, the conflict error behavior is determined by the clients, not by
what they are doing or the secondary identities they are working on
behalf of. The WG considered (and I hope still considers) this
acceptable on the basis that it is an error case anyway, and all we are
doing is creating predictable behavior for the rror handling, not
"correct" behavior.
Yours,
Joel
On 7/13/15 7:09 PM, Jeffrey Haas wrote:
Andy,
On Mon, Jul 13, 2015 at 03:58:22PM -0700, Andy Bierman wrote:
On Mon, Jul 13, 2015 at 3:46 PM, Jeffrey Haas <[email protected]> wrote:
Note that the priority MUST not be user-supplied. It should be derived
from
the credentials. Letting the user set the priority may be inappropriate
security.
This approach would mean that the I2RS client acting as a broker
would need a different session for each secondary client.
It seems more useful to allow the client to use 1 session,
and just require that each edit be from a specific secondary identity.
(e.g., add a secondary-identity parameter to the edit operation).
The proposed solution of an XML attribute allows every node
in an edit to be from a different secondary identity.
I don't object to moving secondary-identity into something that may be able
to vary on a per-edit transaction.
I had started to write that priority is associated with their client and
that edits are likely done on behalf of a given secondary-id. Then I had a
realization prompted by the proxy use case: In order to carry through the
appropriate priority, it would be necessary to similarly carry through the
primary identity in order to have that identity/priority association. This
seems a bit contrary to the idea of a proxy operating as "root".
Joel/Alia, would you please comment how you intended the multi-headed
control case to operate with regard to associated identity and priority?
I believe having the priority set per-session likely matches our use case.
In the event a different priority is expected, the user would use a
different session with different credentials.
I thought the client priority is configured in advance by the
administrator. It makes no sense to have each client
state their own priority. This is useless for resolving conflicts
between clients.
Priority associated to client identity is what is intended.
IMO, priority 0 is the highest, and can only be used
by the system itself. Priority 1 is the next highest.
This is probably reasonable. It also means you've already tripped into the
usual descriptive issue of lower is better; better is not higher. :-)
-- Jeff
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
