Return-Path: 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 596881321F1 for ; Wed, 9 Aug 2017 07:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9FG3rmzn88-Z for ; Wed, 9 Aug 2017 07:35:06 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD26513232C for ; Wed, 9 Aug 2017 07:35:05 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id s6so37523571qtc.1 for ; Wed, 09 Aug 2017 07:35:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=B8VVnV8RqkcLDE69deyyZ95CqeWd62mjqJlogtPB/ho=; b=ZWBIJVbvZBoIf9RBz983gkEu2GqjDNRe10FG1POf31tKnCui+AxTjH3xQOlK1f9yH/ +wP0wPXSlMfxxEpVY09KwpRK5OqEBfqmqEYR0/p2cByTxWXLqAqKEaJPq0lzP9wALl34 3zOUFT9i+iOv8WWFl5lgYo4yqUmpU1wKoxXVstxtfRmPzQL9crEusIuiUIgh3GAzZnpb MNglWlLtlkqIYexjsNDPixcc0Sbyc77nfcaEquoDCdqMFAr9WklpkBbWktQ3tuAuFp8O SL5/0SOHRM4151bnrN4qVw8J7SYoddva8qmjQ/pC15VohDMTqYBOw0lpYh/YSl2DdJhg 0t/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=B8VVnV8RqkcLDE69deyyZ95CqeWd62mjqJlogtPB/ho=; b=ibyeqU0vDTXnD3tS8fSHOBMHzfqhkaMmimyXxj0XRQ2b4w/gCdazH0rRuhc3kGwAJM odcPB2s1oiX9SgtLRCEluaxiztJvLgPF1cLgXGX2GR/TymWqhuPt415PWfgMmdnWDL4s rGGYIK1OMFMmj+XNhQMT48DXb+AwhuSDhY77yV2vrSQ1y3X3Q7ZJBMQmeBtnTqrAqVGY 40IkAPg3aO0rA47NzgJgo0vl0WApLiwkVoTpx04lBk+QY2cJDEtvxTsYVnjevqQUJyjP yR2Pysg9M8MQ/AXHHe7joHVt3h5RivIczqpQl7qxqZmX+nHYJRXd/fUmz280diHFu+YB jP+A== X-Gm-Message-State: AHYfb5jXKCGKW9XdU599kMid9qCY3evjW0zz8d7fGOiBZ6E1+XAfXLRS BwhsxcudOxe0+7IbwCP1ttxbIU2uGKh2 X-Received: by 10.200.42.176 with SMTP id b45mr11256846qta.76.1502289304264; Wed, 09 Aug 2017 07:35:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.1.194 with HTTP; Wed, 9 Aug 2017 07:35:02 -0700 (PDT) In-Reply-To: References: <54CA5E71-F469-4FD9-AF29-21985B454CAE@gmail.com> From: Herbert Van de Sompel Date: Wed, 9 Aug 2017 16:35:02 +0200 Message-ID: Subject: Re: Request to register "identifier" relation type To: link-relations Cc: Peter Williams , Geoffrey Bilder , Michael Nelson , Simeon Warner , "John A. Kunze" , Ed Summers , Herbert Van de Sompel Content-Type: multipart/alternative; boundary="001a1135228a54a3db055652fc47" Archived-At: X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 14:35:08 -0000 --001a1135228a54a3db055652fc47 Content-Type: text/plain; charset="UTF-8" On Sat, Aug 5, 2017 at 2:56 PM, Herbert Van de Sompel wrote: > On Aug 5, 2017, at 13:59, Ed Summers wrote: > > > >> On Aug 5, 2017, at 3:38 AM, Herbert Van de Sompel > wrote: > >> > > I wonder if rather than adding another link relation to the mix if the > HTML folks would be willing to update rel=bookmark to allow for usage with which ought to make it amenable to use in an > HTTP header as some other HTML relations are (e.g. alternate). The > semantics of bookmark speak directly to the issue of persistence that your > I-D seems to be addressing. > > > > Our I-D acknowledges that the semantics of "identifier" are similar to > "bookmark". But "bookmark" is explicitly not allowed in (and hence > Link). One has to assume there were/are reasons for that choice because > other rel types declared in HTML can be used in . > > Update: Since, the above mail exchange regarding the suggested use of "bookmark" the following actions were taken: * On August 5, Ed Summers posted a question regarding applying "bookmark" to to the WHATWG list, see https://lists.w3.org/Archi ves/Public/public-whatwg-archive/2017Aug/0001.html. There are no responses to this post, so far. * On August 9, Ed Summer posted a similar question to WHATWG/HTML GitHub, see https://github.com/whatwg/html/issues/2899. There is a reaction from @annevk who (1) speculates that the reason "bookmark" is not to be used with might be in order not to overlap with "canonical" (2) suggests the use of "canonical" :-) * Michael Nelson has further explored "bookmark" and has confirmed that there effectively is a reason for not allowing "bookmark" in . It is related to its target use case: surfacing a link for content contained in a *part* of a page. Hence, Michael concludes that making "bookmark" usable with will most likely not happen. @annevk's GitHub response does not seem to contradict that. Michael based his findings on studying http://tantek.com/log/2002/11.html#L20021128t1352 and https://html.spec.whatwg.org/multipage/links.html#link-type-bookmark. He may write another blog post about this, but, for now, here's how he explained on Twitter https://twitter.com/i/moments/895081563653902336 As a summary, thus far, of these discussions: * We have further explained, in a special-purpose blog post, that "canonical" is not applicable for the use cases we describe in our I-D. * We have shown that there is a reason why "bookmark" is not usable with . While the relation type name suggests it has the appropriate semantics intended by "identifier", its intended use is surfacing a link for content contained in a *part* of a page. That's not the intention of "identifier", which is about surfacing another URI (for the purpose of referencing) for an entire resource. We agree with Ed Summers that we need to use the web we have, where possible. To that end, we had included an analysis in our I-D explaining why certain existing rel types are not applicable. Based on the discussions, here, we will be able to further clarify that analysis in a next iteration of our I-D. But the analysis will still reach the conclusion that these existing relation types are not applicable. As such, we also reconfirm our request to register "identifier". Greetings Herbert -- Herbert Van de Sompel Digital Library Research & Prototyping Los Alamos National Laboratory, Research Library http://public.lanl.gov/herbertv/ http://orcid.org/0000-0002-0715-6126 == --001a1135228a54a3db055652fc47 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= at, Aug 5, 2017 at 2:56 PM, Herbert Van de Sompel <hvdsomp@gmail.com&g= t; wrote:
On Aug 5, 2017, at 13:59, Ed Summers <ehs@pobox.com> wrote:
>
>> On Aug 5, 2017, at 3:38 AM, Herbert Van de Sompel <hvdsomp@gmail.com> wrote:=
>>
> I wonder if rather than adding another link r= elation to the mix if the HTML folks would be willing to update rel=3Dbookm= ark=C2=A0
to allow for usage with <link> which ought to make it amena= ble to use in an HTTP header as some other HTML relations are (e.g. alterna= te). The semantics of bookmark speak directly to the issue of persistence t= hat your I-D seems to be addressing.
>

Our I-D acknowledges that the semantics of "identifier" ar= e similar to "bookmark". But "bookmark" is explicitly n= ot allowed in <link> (and hence Link). One has to assume there were/a= re reasons for that choice because other rel types declared in HTML can be = used in <link>.


Update: Since, the = above mail exchange regarding the suggested use of "bookmark" the= following actions were taken:

* On August 5, Ed S= ummers posted a question regarding applying "bookmark" to <lin= k> to the WHATWG list, see=C2=A0https://lists.w3.org/Archives/= Public/public-whatwg-archive/2017Aug/0001.html. There are no respo= nses to this post, so far.

* On August 9, Ed Summe= r posted a similar question to WHATWG/HTML GitHub, see=C2=A0https://github.co= m/whatwg/html/issues/2899. There is a reaction from @annevk who (1= ) speculates that the reason "bookmark" is not to be used with &l= t;link> might be in order not to overlap with "canonical" (2) = suggests the use of "canonical" :-)=C2=A0

* Michael Nelson has further explored "bookmark" and has confir= med that there effectively is a reason for not allowing "bookmark"= ; in <link>. It is related to its target use case: surfacing a link f= or content contained in a *part* of a page. Hence, Michael concludes that m= aking "bookmark" usable with <link> will most likely not ha= ppen. @annevk's GitHub response does not seem to contradict that.=C2=A0= Michael based his findings on studying http://tantek.com/log/2002/11.<= wbr>html#L20021128t1352 and=C2=A0https://html.s= pec.whatwg.org/multipage/links.html#link-type-bookmark. He ma= y write another blog post about this, but, for now, here's how he expla= ined on Twitter https://twitter.com/i/moments/895081563653902336

As a summary, thus far, of these discussions:

* We have further explained, in a special-purpose b= log post, that "canonical" is not applicable for the use cases we= describe in our I-D.=C2=A0

* We have shown that t= here is a reason why "bookmark" is not usable with <link>. = While the relation type name suggests it has the appropriate semantics inte= nded by "identifier", its intended use is surfacing a link for co= ntent contained in a *part* of a page. That's not the intention of &quo= t;identifier", which is about surfacing another URI (for the purpose o= f referencing) for an entire resource.

We agree wi= th Ed Summers that we need to use the web we have, where possible. To that = end, we had included an analysis in our I-D explaining why certain existing= rel types are not applicable. Based on the discussions, here, we will be a= ble to further clarify that analysis in a next iteration of our I-D. But th= e analysis will still reach the conclusion that these existing relation typ= es are not applicable. As such, we also reconfirm our request to register &= quot;identifier".

Greetings
--001a1135228a54a3db055652fc47--