On Thu, Aug 15, 2013 at 10:13 AM, SM <sm(_at_)resistor(_dot_)net> wrote:
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"?
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.
"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?
A client could support HTTP for the template retrieval but only HTTPS for
the service itself, for all the usual privacy and security reasons.
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?
-MSK