On Thu, Aug 15, 2013 at 10:40 AM, SM <s...@resistor.net> wrote: > > From Section 3.1: > > "expires: A timestamp indicating a time beyond which the score > reported is likely not to be valid. Expressed as the number of > seconds since January 1, 1970 00:00 UTC. See Section 5 for > discussion." > > And Section 5: > > 'A reputon can contain an "expires" field indicating a timestamp after > which the client SHOULD NOT use the rating it contains, and SHOULD' > > The "expires" field uses "HTTP-date". It is easier to code for one > timestamp format instead of two (see Unix timestamp in Section 3.1). >
By that I assume you mean the Expires field in the HTTP exchange, and not this value. An HTTP exchange can contain multiple reputons. The expiration timestamp might be different for each. > > In Section 3.1: > > "An application service provider might operate with an enhanced form > of common services, which might in turn prompt development and > reporting of specialized reputation information." > > I don't see anything actionable in the above. > Taken out of context, of course not. The text that follows indicates that the default set of reputon attributes might not be sufficient for describing all of the information needed in a reputon for a given application space. It could be necessary to document additional attributes and their syntaxes and semantics for those applications. Those need to be done in separate documents that register those applications. > Why was "specification required" chosen for the Reputation Applications > Registry? > > As alluded to above, there can be quite a bit of information needed for an application to be defined beyond the defaults assumed when a name is registered. There didn't seem to be any need to require such definition to be in an IETF document, but it also seems as though more information than what's needed with just FCFS or DE or the other lesser rules is appropriate either. -MSK
