On Thu, Aug 15, 2013 at 10:13 AM, SM <sm@xxxxxxxxxxxx> wrote:
An operator that calculates reputation values on demand would conceivably give a new value for every query. If a client wants that up-to-the-moment accuracy, then Expires is counterproductive. On the other hand, an operator that calculates reputation values daily could indicate this by setting an Expires field of either a day (86400) or the total time between "now" and the next calculation.
The latter case is likely more prevalent, but it doesn't seem like saying "MUST" and requiring a value of 0 for the former case is strictly the right solution.
A client could support HTTP for the template retrieval but only HTTPS for the service itself, for all the usual privacy and security reasons.
The draft-iet-repute-model reference is a down-ref.
I agree, the model document should be considered for PS instead.
"A server receiving a query about an application it does not
recognize or explicitly support support (e.g., by virtue of
private agreements or experimental extensions) MUST return a
404 error code."
There is a typo: "support support".
Fixed.
Are there other cases where a 404 is appropriate? I am asking the question as there is a string of proposals built upon RFC 2616 which attempt to use HTTP status codes to communicate errors for the layered protocol.
I don't believe so. The only cases we can think of are those where the supported application does or does not exist, and the service being queried does or does not have data about the subject. Elsewhere we describe that there's a specific mechanism to say in a valid reply that no data are available, so that handles the second question. You only get to the second question if the answer to the first is "yes", which leaves the first answer of "no" that needs handling specified.
In Section 3.2:
"and SHOULD include an Expires field (see Section 14.21 of [HTTP])
indicating a duration for which the template is to be considered
valid by clients and not re-queried."
Why is this a RFC 2119 SHOULD? There is a "SHOULD NOT" following that paragraph with a "don't query for a day if there isn't an Expires field". Wouldn't it be easier to have "MUST include the Expires field"?
The latter case is likely more prevalent, but it doesn't seem like saying "MUST" and requiring a value of 0 for the former case is strictly the right solution.
"The template file might contain more than one template. Such a file
MUST have each template separated by a newline (ASCII 0x0D)
character."
As this is line oriented it may be better to have CRLF.
Why is that?
In Section 3.3:
"A server SHOULD include support for providing service over HTTP"
Is there a case where the service with work if the server does not support HTTP?
In Section 5:
"The reputation service itself will use HTTP or other transport
methods to issue queries and receive replies. Those protocols have
registered URI schemes and, as such, presumably have documented
security considerations."
This is odd. What other protocols are there to retrieve the URI template?
Any URI scheme is supported. Only HTTP/HTTPS are currently implemented at the moment.
If I understood the draft, the Proposed Standard angle is:
http://{service}/{application}/{subject}/{assertion}
with a "application/reputon+json" response. Why should that be a Proposed Standard?
That's not "the" angle, it's one possible template.
Does it not qualify as a Proposed Standard? If not, why not? Will it fail to interoperate?
Does it not qualify as a Proposed Standard? If not, why not? Will it fail to interoperate?
-MSK