[weirds] REST-pect-ful

[Olaf Kolkman <[e-mail]>]

(Also see mail with subject: "Setting the WEIRDS IETF 84 agenda")

Colleagues,

I believe that sorting out how to do service differentiation during an early stage of protocol development is useful.

What I can see is that at some point there is a resource, an object with several elements, for which a local policy of a data provider is that some of its clients are required to have access to that information while others are required to not gain access. A typical example being Contact information whereby a telephone number needs to be made available to law-enforcement, while in general that sort of information is considered privacy sensitive and is not to be shipped to the general public. Note this is an example of a local policy that is not unlikely.

The premise is that we want the protocol to support these sort of policy choices (Who sets the policy is not within scope of the working group).

The other premise is that we "use standard features of HTTP to support differential service levels to different classes of user." [Charter]

The question is what approach do we take, in general, in order to respect the RESTful approach and still differentiate.

It seems that draft-kong-dnrd-ap-response-json section 3.3 uses a mechanism that we can base a straw-man on: 

The resource that is returned as for a query for a contact returns a general identifier with elements that contain URIs for the address, phone number and other person information. If you want to resolve those elements in more detail you will have to do a new query. That query might be refused based on authentication.

I wonder if this approach makes sense, and whether there are better alternatives being considered.

Anther method I thought of is serve up all elements but fill in 'REFUSED', or another magic string or code that indicates the client is not allowed to see those elements. But that doesn't seem very RESTful and I dismissed it.

Questions to the group.

Is the approach as described above (and worked out in Kong et al.'s Internet Draft) an approach we can consent on? Are there alternatives? Are there issues with this approach that need further thought.

Since the answer to this question sets direction

--Olaf














The output of this discussion could end up in draft-designteam-weirds-using-http



_______________________________________________________ 
Olaf Kolkman -- NLnet Labs
http://www.nlnetlabs.nl/