IETF Logo Mail Archive

Re: [link-relations] NEW RELATION REQUEST - pingback

Mark Nottingham <mnot@mnot.net> Wed, 11 August 2010 03:34 UTC

Return-Path: <mnot@mnot.net>
X-Original-To: link-relations@core3.amsl.com
Delivered-To: link-relations@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA3273A6886 for <link-relations@core3.amsl.com>; Tue, 10 Aug 2010 20:34:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.157
X-Spam-Level:
X-Spam-Status: No, score=-105.157 tagged_above=-999 required=5 tests=[AWL=-2.558, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYWLeTQcBPGu for <link-relations@core3.amsl.com>; Tue, 10 Aug 2010 20:34:38 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id C0FC03A679C for <link-relations@ietf.org>; Tue, 10 Aug 2010 20:34:38 -0700 (PDT)
Received: from chancetrain-lm.mnot.net (unknown [118.209.94.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8ABCE22E253; Tue, 10 Aug 2010 23:35:07 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="us-ascii"
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <Pine.LNX.4.64.1008110320320.11977@ps20323.dreamhostps.com>
Date: Wed, 11 Aug 2010 13:35:25 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <B287E435-5C63-448B-ACD9-E3319FCDBF14@mnot.net>
References: <Pine.LNX.4.64.1008102113040.11992@ps20323.dreamhostps.com> <69D54950-1FE2-4714-9FED-569142BBF1A4@mnot.net> <Pine.LNX.4.64.1008110320320.11977@ps20323.dreamhostps.com>
To: Ian Hickson <ian@hixie.ch>
X-Mailer: Apple Mail (2.1081)
Cc: link-relations@ietf.org
Subject: Re: [link-relations] NEW RELATION REQUEST - pingback
X-BeenThere: link-relations@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <link-relations.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/link-relations>, <mailto:link-relations-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/link-relations>
List-Post: <mailto:link-relations@ietf.org>
List-Help: <mailto:link-relations-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/link-relations>, <mailto:link-relations-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Aug 2010 03:34:40 -0000

On 11/08/2010, at 1:22 PM, Ian Hickson wrote:

> On Wed, 11 Aug 2010, Mark Nottingham wrote:
>> 
>> Overall looks good; two issues:
>> 
>> 1) the template should be in the draft.
> 
> The draft is frozen. Is there no way to register a link relation for old 
> drafts? The HTML4 relations were registered without modifying HTML4, no?

Yes - they were registered in an RFC. 

> 2) a document published on a personal web site doesn't meet the 
>> requirement for the reference to be an RFC or Open Standard.
>> 
>> RE #2: there are a couple of things you could do to address this, but 
>> probably the easiest would be to submit it to the RFC Editor for 
>> publication as an independent submission Informational RFC. If you'd 
>> like details on how to do this, just ask.
> 
> I'm not especially interested in publishing this document through the IETF 
> process (it would appear to be entirely busywork with no upside); does 
> that mean that it isn't possible to register this relation?

If you meet the "RFC or Open Standard" test, it's possible to register it.

Note that publishing on the independent submission Informational RFC track isn't really "through the IETF process" -- it's at the discretion of the RFC Editor, which is a separate entity. See:
  http://www.rfc-editor.org/indsubs.html
  http://tools.ietf.org/html/rfc4846
  http://tools.ietf.org/html/rfc5742

While I can't say that it's necessarily a quick process, the amount of work involved (beyond draft formatting) is relatively low, and there are a few upsides, including:

1) RFCs are institutionally guaranteed not to change over time; you say that the spec is frozen, but there aren't checks or balances, nor conventions in place, to prevent future changes.
2) When you die and your Web site disappears, an RFC will have a better chance of persisting in an unambiguous state.

Cheers,

--
Mark Nottingham     http://www.mnot.net/

v2.23.0 | Report a Bug | By Email