Re: [link-relations] NEW RELATION - canonical

Julian Reschke <julian.reschke@gmx.de> Wed, 01 June 2011 22:27 UTC

Return-Path: <julian.reschke@gmx.de>
X-Original-To: link-relations@ietfa.amsl.com
Delivered-To: link-relations@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B219E072C for <link-relations@ietfa.amsl.com>; Wed, 1 Jun 2011 15:27:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.027
X-Spam-Level:
X-Spam-Status: No, score=-104.027 tagged_above=-999 required=5 tests=[AWL=-1.428, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cUVibExi38dF for <link-relations@ietfa.amsl.com>; Wed, 1 Jun 2011 15:27:49 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 65AB4E06D1 for <link-relations@ietf.org>; Wed, 1 Jun 2011 15:27:48 -0700 (PDT)
Received: (qmail invoked by alias); 01 Jun 2011 22:27:45 -0000
Received: from p508FA928.dip.t-dialin.net (EHLO [192.168.178.36]) [80.143.169.40] by mail.gmx.net (mp011) with SMTP; 02 Jun 2011 00:27:45 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1+5AxZ99O6554NWepPsecO9/KNzr3Dhc2XCgWW6gb 71qeCuQeNeOaQY
Message-ID: <4DE6BCD5.2040602@gmx.de>
Date: Thu, 02 Jun 2011 00:27:33 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
To: Bjoern Hoehrmann <derhoermi@gmx.net>
References: <BANLkTimg41ARufdRi0pMCP7LXSmqsgiuRw@mail.gmail.com> <4DBDBDE3.7060502@gmx.de> <7iddu6hjj1u9n4bt8fg4l1fll6m3u00jmv@hive.bjoern.hoehrmann.de>
In-Reply-To: <7iddu6hjj1u9n4bt8fg4l1fll6m3u00jmv@hive.bjoern.hoehrmann.de>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: link-relations <link-relations@ietf.org>
Subject: Re: [link-relations] NEW RELATION - canonical
X-BeenThere: link-relations@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <link-relations.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 01 Jun 2011 22:27:50 -0000

On 2011-06-02 00:18, Bjoern Hoehrmann wrote:
> * Julian Reschke wrote:
>> On 01.05.2011 19:34, Frank Ellermann wrote:
>>> On 2011-04-15 I posted "NEW RELATION - canonical", and one day later I
>>> amended it by
>>> s/similar similar/similar/.  After two weeks that's now an "ETMO"
>>> (error time out), and
>>> RFC 5988 offers no default accept or reject rule.
>>> ...
>>
>> I did answer in
>> <http://www.ietf.org/mail-archive/web/link-relations/current/msg00186.html>,
>> right?
>>
>> That being said, I totally agree this is moving too slowly.
>
> You said that a month ago, where the request was already two weeks old.
> In your answer you only asked a question; as far as I can tell none of
> the designated experts have so far approved or denied the request. So,
> "Within at most 14 days of the request, the Designated Expert(s) will
> either approve or deny the registration request" does not seem true. I,
> well, I am mostly wondering why anyone would have thought it a good idea
> to make this promise in the specification. Any thoughts on that? Keeping
> in mind that this promise has been broken several times, as far as I can
> tell.
>
> (I think it is an unreasonable requirement and am looking for what to
> tell the next person who proposes such a requirement so they abandon the
> idea early on, I don't really care about how many days it takes to
> register a link relation; in this instance, people could just have said
> they want Approve or Deny _now_ and I do think they would have gotten
> that timely, but dealing in such absolutes often leads to unhappiness.)

I agree with you that it's an unreasonable requirement.

I'm also forwarding this message to the people who've been working on 
the spec, but haven't submitted anything yet...

Best regards, Julian