Skip to main content

A Media Type for Reputation Interchange
RFC 7071

Yes

(Pete Resnick)

No Objection

(Adrian Farrel)
(Brian Haberman)
(Gonzalo Camarillo)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Sean Turner)
(Spencer Dawkins)
(Stephen Farrell)
(Stewart Bryant)

Note: This ballot was opened for revision 12 and is now closed.

(Barry Leiba; former steering group member) (was Discuss) Yes

Yes (2013-09-15)
Thanks for the excellent work in resolving the remaining issues.

(Pete Resnick; former steering group member) Yes

Yes (for -12)

                            

(Adrian Farrel; former steering group member) No Objection

No Objection (for -12)

                            

(Benoît Claise; former steering group member) No Objection

(Brian Haberman; former steering group member) No Objection

No Objection (for -12)

                            

(Gonzalo Camarillo; former steering group member) No Objection

No Objection (for -12)

                            

(Jari Arkko; former steering group member) No Objection

No Objection (for -12)

                            

(Joel Jaeggli; former steering group member) No Objection

No Objection (for -12)

                            

(Martin Stiemerling; former steering group member) No Objection

No Objection (for -12)

                            

(Richard Barnes; former steering group member) No Objection

No Objection (2013-09-11 for -12)
And the antiparticle of the reputon is... a disreputon?

It seems strange that the context for the reputon is relegated to a parameter of the media type, when it's really a semantic attribute, not a type/encoding attribute.  Suggest moving it inside the reputon or reputon collection structures.

In "sample-size": JSON doesn't have a notion of the length of an integer, so saying "64-bit" here seems odd, unless you mean that it MUST NOT exceed 2**64-1.

I agree with Barry's comment that a collection of reputons (repu-meson?) should be an array rather than an object.

(Sean Turner; former steering group member) No Objection

No Objection (for -12)

                            

(Spencer Dawkins; former steering group member) No Objection

No Objection (for -12)

                            

(Stephen Farrell; former steering group member) No Objection

No Objection (for -12)

                            

(Stewart Bryant; former steering group member) No Objection

No Objection (for -12)

                            

(Ted Lemon; former steering group member) No Objection

No Objection (2013-09-10 for -12)
If I am reading this ABNF correctly:
     reputon = "{" [ reputon-object
         *(value-separator reputon-object) ] "}"

     reputon-object = "reputon" name-separator response-set

...then a reputon is one or more reputon objects, each of which is denoted with the string "reputon".   IOW:

{ "reputon": { ... }, "reputon": {...} }

Is that correct?   If so, isn't a little weird to use "reputon" as the string that denotes a reputon object, which is a _part_ of a reputon, not a whole reputon?   Or am I just not understanding the ABNF (which is quite possible—I'm hardly an expert).

The relationship between the term "clutch hitter" and "choke" is not going to be obvious to many readers (e.g., not obvious to me).   This may not be the best example to use to make the point you are making here.

Are assertions not allowed to contain whitespace characters?   I ask because you use names like "choke-hitter" and "is-good" instead of "choke hitter" and "is good".   Given that these appear in quotes, it seems unnecessary to substitute dashes for spaces.