19 lines
3.3 KiB
Plaintext
19 lines
3.3 KiB
Plaintext
RFC: Action stamps
|
|
<p>This is a request for comment on a convention for uniquely identifying user actions on the Internet. The motivating context was identifying commit changesets in version-control systems in a way independent of the specific VCS. It is anticipated that this format will have uses in recording many other similar sorts of transactions, including actions on web interfaces, where we want a simple cookie identifying “who did this and when”.</p>
|
|
<p><span id="more-3872"></span></p>
|
|
<p>The proposed format is designated an “action stamp” and consists of an <a href="https://www1.ietf.org/rfc/rfc3339.txt">RFC3339 timestamp</a> in Zulu time, followed by an exclamation point, followed by an <a href="http://www.w3.org/Protocols/rfc822/">RFC822 address</a> (technically, an “addr-spec” as defined in 6.1). </p>
|
|
<p>Thus: 2011-10-25T15:11:09Z!fred@foonly.com</p>
|
|
<p>Advantages of this format include:</p>
|
|
<p>* <b>Uniqueness:</b> In distributed VCSes and elsewhere, email addresses are widely accepted as primary identity keys. The timestamp can be extended to subsecond precision to lower collision probability as far as desired. </p>
|
|
<p>* <b>Well-definedness:</b> RFC3339 and RFC822 are well-written, widely accepted standards with lots of existing software support.</p>
|
|
<p>* <b>Ease of parsing:</b> The format is textual, syntactically unambiguous, and easily mined from surrounding text. It is readily distinguishable from (a) a plain timestamp, (b) a filename, or (c) a standalone email address. Humans can read it easily.</p>
|
|
<p>* <b>Good sorting properties:</b> RFC3339 is a profile of ISO8601, which is designed so that lexical sort order coincides with timestamp order. Action stamps inherit this.</p>
|
|
<p>* <b>Simplicity and compactness:</b> Really, how could it get any simpler? Exactly one character of overhead.</p>
|
|
<p>Now I’ll address some possible points of contention with this proposal.</p>
|
|
<p>1. <b>Why an exclamation point?</b> Because nothing else uses it. Not since bang-path addresses went out of style, anyway.</p>
|
|
<p>2. <b>Bletch. The T in the timestamp is ugly.</b> Yes, it is. Live with it; whitespace there would break the action stamp into two tokens, which is undesirable for a cookie that we want to be readily machine-parsable. Also the T is a useful cue that the reader is looking at RFC3339/ISO8601.</p>
|
|
<p>3. <b>Is the trailing ‘Z’ on the timestamp really necessary?</b> Yes, it is. Local times are ambiguous without a location – you want something in the action stamp that makes it clear what timezone is intended and the easier way to do that is to mandate Zulu time (UTC/GMT) in the format. The Z is a reminder that it’s Zulu time.</p>
|
|
<p>4. <b>Email addresses change, expire, and one person may have several.</b> True, but the same would be true of any other identity token we could use in these. Email addresses have the desirable properties of being simple, universal, and implicitly describing a communication channel to the person. Experience with DVCSes, PGP keys, and ssh keys has taught us that the edge cases are manageable.</p>
|
|
<p>5. <b>Er, there isn’t really much to this proposal, is there?</b> That’s right. Brutal simplicity is part of the point.</p>
|
|
<p>Comments and criticism welcome. If reaction is positive I might try to turn this into an actual IETF RFC.</p>
|