From ian@hixie.ch Sun Aug 8 21:44:49 2010 Return-Path: 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 3886E3A68B9 for ; Sun, 8 Aug 2010 21:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.249 X-Spam-Level: X-Spam-Status: No, score=-0.249 tagged_above=-999 required=5 tests=[AWL=-2.141, BAYES_40=-0.185, SUBJ_ALL_CAPS=2.077] 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 t5iGonzZb4MI for ; Sun, 8 Aug 2010 21:44:48 -0700 (PDT) Received: from homiemail-a46.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id 919D43A690F for ; Sun, 8 Aug 2010 21:30:22 -0700 (PDT) Received: from homiemail-a46.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a46.g.dreamhost.com (Postfix) with ESMTP id F3EEA3E4065 for ; Sun, 8 Aug 2010 21:30:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=hixie.ch; h=date:from:to:subject :message-id:mime-version:content-type; q=dns; s=hixie.ch; b=Jkv0 yks3ZbefDeXT9xHOpFTxCc6rS3MFd6IHor6oRO94dpL9iA9Gs5KoWmpKTt+XtEtv q4KUfLWzMYtcGT3XwUW/LOeESNE+HfDpDKnX4mGJK6qLMM9iNSRCU97VNzIBqeCE OEJv6pKKyjyVJrVVeFm5MqGc/FLonuz9udG/atI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hixie.ch; h=date:from:to :subject:message-id:mime-version:content-type; s=hixie.ch; bh=rQ 9PXY/Duxd6sppNormp2RV7EjY=; b=FnErYZZfrYOJH+AggDw0wiss3bYBfk2IAm M4utKn6FKe94QcTNRMlsO5S50bEXX1BNYo/Iy4taSArAZAlLVDAEdmCN8Z1ADKKw HnChqsfid2FuZDmZCsd9r6Tju79dr26HyGdaPV6TGMDRr72BZaRNnFCGiNYA4FYY +hAAKjGgI= Received: from ps20323.dreamhostps.com (ps20323.dreamhost.com [69.163.222.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: internal@index.hixie.ch) by homiemail-a46.g.dreamhost.com (Postfix) with ESMTPSA id F0B5E3E4062 for ; Sun, 8 Aug 2010 21:30:39 -0700 (PDT) Date: Mon, 9 Aug 2010 04:30:39 +0000 (UTC) From: Ian Hickson To: link-relations@ietf.org Message-ID: Content-Language: en-GB-hixie Content-Style-Type: text/css MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [link-relations] NEW APP DATA X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 04:44:49 -0000 o Application Name: HTML o Description: Effect on a and area elements o Default Value: Not allowed o Notes: The following values should have "Hyperlink" for this field: alternate, appendix, bookmark, chapter, contents, copyright, first, glossary, help, index, first, last, license, next, prev, previous, section, start, subsection, up. o Specification: http://www.whatwg.org/specs/web-apps/current-work/complete.html#iana-registry o Application Name: HTML o Description: Effect on link elements o Default Value: Not allowed o Notes: The following values should have "Hyperlink" for this field: alternate, appendix, chapter, contents, copyright, first, glossary, help, index, first, last, license, next, prev, previous, section, start, subsection, up. The following values should have "External Resource Link" for this field: stylesheet. o Specification: http://www.whatwg.org/specs/web-apps/current-work/complete.html#iana-registry -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From julian.reschke@gmx.de Mon Aug 9 00:00:00 2010 Return-Path: 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 4B0243A6A80 for ; Mon, 9 Aug 2010 00:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[AWL=-2.080, BAYES_40=-0.185, 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 qsTvBuXvF3r9 for ; Sun, 8 Aug 2010 23:59:59 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id BD70D3A6A74 for ; Sun, 8 Aug 2010 23:59:57 -0700 (PDT) Received: (qmail invoked by alias); 09 Aug 2010 07:00:30 -0000 Received: from p508FE3AB.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.227.171] by mail.gmx.net (mp016) with SMTP; 09 Aug 2010 09:00:30 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18H/rZ5RecHttY5LwCIV+VL181yE7IF8ykVny0vCv qzw3VM8KJSSCef Message-ID: <4C5FA78D.80108@gmx.de> Date: Mon, 09 Aug 2010 09:00:29 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Ian Hickson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: link-relations@ietf.org Subject: Re: [link-relations] NEW APP DATA X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 07:00:00 -0000 On 09.08.2010 06:30, Ian Hickson wrote: > > o Application Name: HTML > o Description: Effect on a and area elements > o Default Value: Not allowed > o Notes: The following values should have "Hyperlink" for this > field: alternate, appendix, bookmark, chapter, contents, > copyright, first, glossary, help, index, first, last, license, > next, prev, previous, section, start, subsection, up. > o Specification: http://www.whatwg.org/specs/web-apps/current-work/complete.html#iana-registry > > o Application Name: HTML > o Description: Effect on link elements > o Default Value: Not allowed > o Notes: The following values should have "Hyperlink" for this > field: alternate, appendix, chapter, contents, copyright, > first, glossary, help, index, first, last, license, next, > prev, previous, section, start, subsection, up. The following > values should have "External Resource Link" for this field: > stylesheet. > o Specification: http://www.whatwg.org/specs/web-apps/current-work/complete.html#iana-registry Ian, could you please have a look at my feedback from July 15: and try to address it? Best regards, Julian From ian@hixie.ch Mon Aug 9 01:42:53 2010 Return-Path: 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 CBB1B3A6855 for ; Mon, 9 Aug 2010 01:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599] 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 ff-4v7NWWNEz for ; Mon, 9 Aug 2010 01:42:52 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id 921213A67CC for ; Mon, 9 Aug 2010 01:42:52 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id 54DF12C006B; Mon, 9 Aug 2010 01:43:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=hixie.ch; h=date:from:to:cc :subject:in-reply-to:message-id:references:mime-version: content-type; q=dns; s=hixie.ch; b=f8Fdsadd7zG3m7oXYnY8/gF/fmHFu Wzs9bWFFzzOy729uHI13/snDpL8M0PBop1PlmNRGVpi1sJSbbCOygAeFROnPlN7O pUCrPO+775AHun1vrkvy8V4vdqxbMlEXFbpzVHAJpAd/0r62cnzCs3a8e1Qh/50g xGs2tT0CSS6hLA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hixie.ch; h=date:from:to :cc:subject:in-reply-to:message-id:references:mime-version: content-type; s=hixie.ch; bh=ta1ehs4xymMZ8pgIg0zyfuudrNs=; b=PDU aBgAaUBw1MZdajgiNt6MHuOvBpNvN0eEoRV/07590nhP7QO+QOeIvsnxau6tGVbO nB+5Wfh2BaTW+UpQvQDV/sGJ2+7xcIkbI7He+Qkfdu7DxUHUxEYEA/AeG717ha2j gVMrKlPJZITho04V0JkWVVZvxPReJ/g/N676+pmk= Received: from ps20323.dreamhostps.com (ps20323.dreamhost.com [69.163.222.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: internal@index.hixie.ch) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTPSA id 4F7682C006A; Mon, 9 Aug 2010 01:43:25 -0700 (PDT) Date: Mon, 9 Aug 2010 08:43:25 +0000 (UTC) From: Ian Hickson To: Julian Reschke In-Reply-To: <4C5FA78D.80108@gmx.de> Message-ID: References: <4C5FA78D.80108@gmx.de> Content-Language: en-GB-hixie Content-Style-Type: text/css MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: link-relations@ietf.org Subject: Re: [link-relations] NEW APP DATA X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 08:42:54 -0000 On Mon, 9 Aug 2010, Julian Reschke wrote: > On 09.08.2010 06:30, Ian Hickson wrote: > > > > o Application Name: HTML > > o Description: Effect on a and area elements > > o Default Value: Not allowed > > o Notes: The following values should have "Hyperlink" for this > > field: alternate, appendix, bookmark, chapter, contents, > > copyright, first, glossary, help, index, first, last, license, > > next, prev, previous, section, start, subsection, up. > > o Specification: > > http://www.whatwg.org/specs/web-apps/current-work/complete.html#iana-registry > > > > o Application Name: HTML > > o Description: Effect on link elements > > o Default Value: Not allowed > > o Notes: The following values should have "Hyperlink" for this > > field: alternate, appendix, chapter, contents, copyright, > > first, glossary, help, index, first, last, license, next, > > prev, previous, section, start, subsection, up. The following > > values should have "External Resource Link" for this field: > > stylesheet. > > o Specification: > > http://www.whatwg.org/specs/web-apps/current-work/complete.html#iana-registry > > could you please have a look at my feedback from July 15: > > > > and try to address it? My apologies, I assumed that the answers to those questions were self-evident in the edits made to the spec recently. The purpose of those flags is to define conformance for HTML. Relations can be updated to define how they work with HTML by using the process described in the Web Linking spec. An example of a relation that we would not want to allow is rel=stylesheet on , which we would want to disallow because it has no effect and is therefore likely an authoring mistake. Similarly, we wouldn't want rel=noreferrer to be allowed on because it's not a link relation, it's a link annotation, and doesn't create hyperlinks without a relation that creates one. Each keyword would have to be taken on a case- by-case basis. Regarding the final parenthetical, I believe the templates fit what is described in the Web Linking spec. HTH, -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From julian.reschke@gmx.de Mon Aug 9 02:36:55 2010 Return-Path: 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 80C5A3A68AB for ; Mon, 9 Aug 2010 02:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.001 X-Spam-Level: X-Spam-Status: No, score=-104.001 tagged_above=-999 required=5 tests=[AWL=-1.402, 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 36v38cysYpvV for ; Mon, 9 Aug 2010 02:36:54 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id EF28E3A677C for ; Mon, 9 Aug 2010 02:36:53 -0700 (PDT) Received: (qmail invoked by alias); 09 Aug 2010 09:37:26 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.147]) [217.91.35.233] by mail.gmx.net (mp024) with SMTP; 09 Aug 2010 11:37:26 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/M+glZrcjMxh5xR1pXq1PvFNLYqR8288reBiDiAk ZZhTSWCNinW7MP Message-ID: <4C5FCC51.60108@gmx.de> Date: Mon, 09 Aug 2010 11:37:21 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Ian Hickson References: <4C5FA78D.80108@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: link-relations@ietf.org Subject: Re: [link-relations] NEW APP DATA X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 09:36:55 -0000 On 09.08.2010 10:43, Ian Hickson wrote: > On Mon, 9 Aug 2010, Julian Reschke wrote: >> On 09.08.2010 06:30, Ian Hickson wrote: >>> >>> o Application Name: HTML >>> o Description: Effect on a and area elements >>> o Default Value: Not allowed >>> o Notes: The following values should have "Hyperlink" for this >>> field: alternate, appendix, bookmark, chapter, contents, >>> copyright, first, glossary, help, index, first, last, license, >>> next, prev, previous, section, start, subsection, up. >>> o Specification: >>> http://www.whatwg.org/specs/web-apps/current-work/complete.html#iana-registry >>> >>> o Application Name: HTML >>> o Description: Effect on link elements >>> o Default Value: Not allowed >>> o Notes: The following values should have "Hyperlink" for this >>> field: alternate, appendix, chapter, contents, copyright, >>> first, glossary, help, index, first, last, license, next, >>> prev, previous, section, start, subsection, up. The following >>> values should have "External Resource Link" for this field: >>> stylesheet. >>> o Specification: >>> http://www.whatwg.org/specs/web-apps/current-work/complete.html#iana-registry >> >> could you please have a look at my feedback from July 15: >> >> >> >> and try to address it? > > My apologies, I assumed that the answers to those questions were > self-evident in the edits made to the spec recently. No, they aren't. > The purpose of those flags is to define conformance for HTML. Yes. I'm not convinced that it's a good idea to move this into the IANA registry, nor am I convinced that the individual flags and their defaults make sense. > Relations can be updated to define how they work with HTML by using the > process described in the Web Linking spec. Do you think it's necessary to do so? Be default, I'd expect any link relation that we have to be usable with by default. It would be very useful to understand why this wouldn't be the case. > An example of a relation that we would not want to allow is rel=stylesheet > on, which we would want to disallow because it has no effect and > is therefore likely an authoring mistake. Similarly, we wouldn't want (Side note: when did acquire @rel???) Are you confident that and always have the same requirements? > rel=noreferrer to be allowed on because it's not a link relation, > it's a link annotation, and doesn't create hyperlinks without a > relation that creates one. Each keyword would have to be taken on a case- > by-case basis. I can see that noreferrer being the only link relation on a is meaningless, but that doesn't mean it needs to be disallowed; there could be other rel values present, after all. > Regarding the final parenthetical, I believe the templates fit what is > described in the Web Linking spec. It does, this is an oversight in the spec. So we'd have to figure out unique names upon registration. Going back to the original issue (hopefully providing context for those who weren't there): we discussed application-specific data when we met in Santa Clara last November. The use case that was provided was a flag that would allow user agents to decide what kind of links need to be followed when going offline or archiving a resource. That makes a lot of sense, and I'd support that kind of flag, hopefully described in a way that isn't totally specific to HTML. What you are proposing is much more; it augments the link type registry with validation hints. I'm totally unconvinced that this is a good idea; in particular given the fact that it's an open question in the HTML WG how far validation should go with respect to these values. Best regards, Julian From ian@hixie.ch Mon Aug 9 10:50:18 2010 Return-Path: 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 12BD528C11D for ; Mon, 9 Aug 2010 10:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599] 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 96YAciaLr4Ea for ; Mon, 9 Aug 2010 10:50:16 -0700 (PDT) Received: from homiemail-a42.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id B774A3A6867 for ; Mon, 9 Aug 2010 10:50:16 -0700 (PDT) Received: from homiemail-a42.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a42.g.dreamhost.com (Postfix) with ESMTP id DADB368C06B; Mon, 9 Aug 2010 10:50:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=hixie.ch; h=date:from:to:cc :subject:in-reply-to:message-id:references:mime-version: content-type; q=dns; s=hixie.ch; b=3YQeGH9xZaxGYMckWOipOrmmyjJIu mJ04r0RwOyG7hu5mGsCLBkhlvdNdgW8TGMn0D9fL4bjnBi3BGRNz7ir0FHQfqtvr enqXD6//BTtt9bCpbXu1aTubUpVX6wCpgy/gCeHFSY70/fStKiS07g47nlk3bjmb KeTLItaQoYHog4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hixie.ch; h=date:from:to :cc:subject:in-reply-to:message-id:references:mime-version: content-type; s=hixie.ch; bh=sNGDsxyLmawm2fBDiI9Am53B7qU=; b=QMp auF1r+zotLgPWzJeLrBIP9JPDE7aUafavtI128nFcEOc3Kmhye8wa2SZcPG9p5gK P3GdZYZf2gsmjpSRvSPQ/u1Fdb+krahc86dQMOJCZQ0xKZqNCkFruxNm+yATrwFO hkiE1TDwpmjDOfK4KlarPmFmJVatd2YCgFHvAT9M= Received: from ps20323.dreamhostps.com (ps20323.dreamhost.com [69.163.222.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: internal@index.hixie.ch) by homiemail-a42.g.dreamhost.com (Postfix) with ESMTPSA id CC9A868C065; Mon, 9 Aug 2010 10:50:50 -0700 (PDT) Date: Mon, 9 Aug 2010 17:50:50 +0000 (UTC) From: Ian Hickson To: Julian Reschke In-Reply-To: <4C5FCC51.60108@gmx.de> Message-ID: References: <4C5FA78D.80108@gmx.de> <4C5FCC51.60108@gmx.de> Content-Language: en-GB-hixie Content-Style-Type: text/css MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: link-relations@ietf.org Subject: Re: [link-relations] NEW APP DATA X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 17:50:18 -0000 On Mon, 9 Aug 2010, Julian Reschke wrote: > > > > The purpose of those flags is to define conformance for HTML. > > Yes. I'm not convinced that it's a good idea to move this into the IANA > registry Nor am I, but that is what the registry was designed to do. > nor am I convinced that the individual flags and their defaults make > sense. Ok... Do I have to convince you for the fields to be registered? > > Relations can be updated to define how they work with HTML by using > > the process described in the Web Linking spec. > > Do you think it's necessary to do so? Be default, I'd expect any link > relation that we have to be usable with by default. It would be > very useful to understand why this wouldn't be the case. It's certainly not the case that any link relation is relevant anywhere. Suppose someone designed a link relation whose purpose was to identify a resource that should be notified any time an API call was made on an HTMLDocument object. That presumably wouldn't make any sense in an Atom feed. Similarly, consider "edit" or "edit-media". While they may be well-defined in the context of Atom, they certainly are not defined to a level that is clear enough for it to make sense to use them in an HTML document, so we wouldn't want to have an author accidentally use them (especially if they were just using them because they thought they could make up new relations and just accidentally clashed with the Atom ones). > > An example of a relation that we would not want to allow is > > rel=stylesheet on, which we would want to disallow because it > > has no effect and is therefore likely an authoring mistake. Similarly, > > we wouldn't want > > (Side note: when did acquire @rel???) As part of the WHATWG's rationalisation of HTML features a few years ago we made all elements that could create hyperlinks be consistently defined (as much as we can given legacy, anyway). > Are you confident that and always have the same requirements? They currently do. If that changes, we'll update the registries. Who knows what the future holds. > > rel=noreferrer to be allowed on because it's not a link > > relation, it's a link annotation, and doesn't create hyperlinks > > without a relation that creates one. Each keyword would have to be > > taken on a case- by-case basis. > > I can see that noreferrer being the only link relation on a is > meaningless, but that doesn't mean it needs to be disallowed; there > could be other rel values present, after all. If something is meaningless, the author benefits from being informed of this, since it is unlikely to be his intent. That's what conformance checkers, and thus conformance definitions, are for. > > Regarding the final parenthetical, I believe the templates fit what is > > described in the Web Linking spec. > > It does, this is an oversight in the spec. So we'd have to figure out > unique names upon registration. I'm just trying to do what the spec says here. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From julian.reschke@gmx.de Mon Aug 9 11:33:14 2010 Return-Path: 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 211FA3A6903 for ; Mon, 9 Aug 2010 11:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.383 X-Spam-Level: X-Spam-Status: No, score=-103.383 tagged_above=-999 required=5 tests=[AWL=-0.784, 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 cIKQg-1RHZ3K for ; Mon, 9 Aug 2010 11:33:08 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id 20A5F3A67B3 for ; Mon, 9 Aug 2010 11:33:07 -0700 (PDT) Received: (qmail invoked by alias); 09 Aug 2010 18:33:40 -0000 Received: from p508FE3AB.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.227.171] by mail.gmx.net (mp056) with SMTP; 09 Aug 2010 20:33:40 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19noUlqs2xngYy3x7zctDoXLHcHfpp/s9EUs0112G QZzQNWb4i8tSDl Message-ID: <4C604A01.8060604@gmx.de> Date: Mon, 09 Aug 2010 20:33:37 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Ian Hickson References: <4C5FA78D.80108@gmx.de> <4C5FCC51.60108@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: link-relations@ietf.org Subject: Re: [link-relations] NEW APP DATA X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 18:33:14 -0000 On 09.08.2010 19:50, Ian Hickson wrote: > On Mon, 9 Aug 2010, Julian Reschke wrote: >>> >>> The purpose of those flags is to define conformance for HTML. >> >> Yes. I'm not convinced that it's a good idea to move this into the IANA >> registry > > Nor am I, but that is what the registry was designed to do. Maybe it's just me, but I don't think it was designed for that. >> nor am I convinced that the individual flags and their defaults make >> sense. > > Ok... Do I have to convince you for the fields to be registered? There are three designated experts, and I assume you need to convince at least one of them. I'm one of those. >>> Relations can be updated to define how they work with HTML by using >>> the process described in the Web Linking spec. >> >> Do you think it's necessary to do so? Be default, I'd expect any link >> relation that we have to be usable with by default. It would be >> very useful to understand why this wouldn't be the case. > > It's certainly not the case that any link relation is relevant anywhere. > Suppose someone designed a link relation whose purpose was to identify a > resource that should be notified any time an API call was made on an > HTMLDocument object. That presumably wouldn't make any sense in an Atom > feed. Similarly, consider "edit" or "edit-media". While they may be > well-defined in the context of Atom, they certainly are not defined to a > level that is clear enough for it to make sense to use them in an HTML > document, so we wouldn't want to have an author accidentally use them > (especially if they were just using them because they thought they could > make up new relations and just accidentally clashed with the Atom ones). My understanding is that we want *future* registered link relations to be broadly usable. So for the example you just mentioned I don't see how a registration would suceed. > ... >> Are you confident that and always have the same requirements? > > They currently do. If that changes, we'll update the registries. Who knows > what the future holds. And add yet another column to the generic registry? Hm. >>> rel=noreferrer to be allowed on because it's not a link >>> relation, it's a link annotation, and doesn't create hyperlinks >>> without a relation that creates one. Each keyword would have to be >>> taken on a case- by-case basis. >> >> I can see that noreferrer being the only link relation on a is >> meaningless, but that doesn't mean it needs to be disallowed; there >> could be other rel values present, after all. > > If something is meaningless, the author benefits from being informed of > this, since it is unlikely to be his intent. That's what conformance > checkers, and thus conformance definitions, are for. The point being it's only meaningless (in HTML) when it's the *only* link relation on the link. Thus, it doesn't make sense to forbid >> Regarding the final parenthetical, I believe the templates fit what is >>> described in the Web Linking spec. >> >> It does, this is an oversight in the spec. So we'd have to figure out >> unique names upon registration. > > I'm just trying to do what the spec says here. In the meantime, what's your take on the part of my email you skipped? Best regards, Julian From ian@hixie.ch Mon Aug 9 12:09:48 2010 Return-Path: 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 31D853A693B for ; Mon, 9 Aug 2010 12:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599] 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 u4lwvW79aKAx for ; Mon, 9 Aug 2010 12:09:46 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id B858A3A67F2 for ; Mon, 9 Aug 2010 12:09:46 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id 0605B2C006B; Mon, 9 Aug 2010 12:10:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=hixie.ch; h=date:from:to:cc :subject:in-reply-to:message-id:references:mime-version: content-type; q=dns; s=hixie.ch; b=DhSnEGv5dMsSQ/heoNAaJhreNFYV3 0piejXMSknuNvhN6PZPp3wxKj3wICy9aVOQpJ14OkRvqDyCHdhB8DAoGpCtywtL0 ShvrZ1NgThjw/TAfYUUDLStm+A0PJul4lbVNtJRnuQo/HQxNSvYLoQ18Re6b/lC6 OhU9JHCzyvpx7I= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hixie.ch; h=date:from:to :cc:subject:in-reply-to:message-id:references:mime-version: content-type; s=hixie.ch; bh=EaCB98xLO/qmMikxztz2Z4BTves=; b=Lu6 HtLFr4woD419jy0Rf9ahsFBzzhYvcNNA3MPjMIlJAuEgxBoO/DuAofFBurrAggCm ooQj/fpNj41p9GGj7wGjowjOp44LptNmLc/TEBSAePyDfjGH7/z+KS22nK/Drjxw j5sXXf3iAZIMbtVuWN0H9k3WpAOIj+UuvUCQW3/U= Received: from ps20323.dreamhostps.com (ps20323.dreamhost.com [69.163.222.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: internal@index.hixie.ch) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTPSA id 015B82C006A; Mon, 9 Aug 2010 12:10:20 -0700 (PDT) Date: Mon, 9 Aug 2010 19:10:20 +0000 (UTC) From: Ian Hickson To: Julian Reschke In-Reply-To: <4C604A01.8060604@gmx.de> Message-ID: References: <4C5FA78D.80108@gmx.de> <4C5FCC51.60108@gmx.de> <4C604A01.8060604@gmx.de> Content-Language: en-GB-hixie Content-Style-Type: text/css MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: link-relations@ietf.org Subject: Re: [link-relations] NEW APP DATA X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 19:09:48 -0000 On Mon, 9 Aug 2010, Julian Reschke wrote: > On 09.08.2010 19:50, Ian Hickson wrote: > > On Mon, 9 Aug 2010, Julian Reschke wrote: > > > > > > > > The purpose of those flags is to define conformance for HTML. > > > > > > Yes. I'm not convinced that it's a good idea to move this into the > > > IANA registry > > > > Nor am I, but that is what the registry was designed to do. > > Maybe it's just me, but I don't think it was designed for that. Well, the field registry exists so as to make it possible to use the registry for HTML, as I understand it. But maybe I'm mistaken, and we're not supposed to use the registry for HTML relations? I'm confused now. > > > nor am I convinced that the individual flags and their defaults make > > > sense. > > > > Ok... Do I have to convince you for the fields to be registered? > > There are three designated experts, and I assume you need to convince at > least one of them. I'm one of those. I see. How can I convince you? > > > > Relations can be updated to define how they work with HTML by > > > > using the process described in the Web Linking spec. > > > > > > Do you think it's necessary to do so? Be default, I'd expect any > > > link relation that we have to be usable with by default. It > > > would be very useful to understand why this wouldn't be the case. > > > > It's certainly not the case that any link relation is relevant > > anywhere. Suppose someone designed a link relation whose purpose was > > to identify a resource that should be notified any time an API call > > was made on an HTMLDocument object. That presumably wouldn't make any > > sense in an Atom feed. Similarly, consider "edit" or "edit-media". > > While they may be well-defined in the context of Atom, they certainly > > are not defined to a level that is clear enough for it to make sense > > to use them in an HTML document, so we wouldn't want to have an author > > accidentally use them (especially if they were just using them because > > they thought they could make up new relations and just accidentally > > clashed with the Atom ones). > > My understanding is that we want *future* registered link relations to > be broadly usable. So for the example you just mentioned I don't see how > a registration would suceed. Well it would be a pretty useless registry if it didn't match reality. :-) I would presume that if someone implemented such a value, getting it registered would be near-automatic, since otherwise we're just going to end up with clashes because people won't be able to register the values they're using, no? > > > Are you confident that and always have the same > > > requirements? > > > > They currently do. If that changes, we'll update the registries. Who > > knows what the future holds. > > And add yet another column to the generic registry? Are columns expensive? > > > > rel=noreferrer to be allowed on because it's not a link > > > > relation, it's a link annotation, and doesn't create > > > > hyperlinks without a relation that creates one. Each keyword would > > > > have to be taken on a case- by-case basis. > > > > > > I can see that noreferrer being the only link relation on a is > > > meaningless, but that doesn't mean it needs to be disallowed; there > > > could be other rel values present, after all. > > > > If something is meaningless, the author benefits from being informed > > of this, since it is unlikely to be his intent. That's what > > conformance checkers, and thus conformance definitions, are for. > > The point being it's only meaningless (in HTML) when it's the *only* > link relation on the link. Thus, it doesn't make sense to forbid > > > just because > > > might be an authoring mistake. That's possible, but that's an issue for HTML, not for the registry, no? > > > > Regarding the final parenthetical, I believe the templates fit > > > > what is described in the Web Linking spec. > > > > > > It does, this is an oversight in the spec. So we'd have to figure > > > out unique names upon registration. > > > > I'm just trying to do what the spec says here. > > In the meantime, what's your take on the part of my email you skipped? > Going back to the original issue (hopefully providing context for > those who weren't there): we discussed application-specific data > when we met in Santa Clara last November. The use case that was > provided was a flag that would allow user agents to decide what kind > of links need to be followed when going offline or archiving a > resource. That makes a lot of sense, and I'd support that kind of > flag, hopefully described in a way that isn't totally specific to > HTML. I have no opinion on this. > What you are proposing is much more; it augments the link type > registry with validation hints. I'm totally unconvinced that this is > a good idea; in particular given the fact that it's an open question > in the HTML WG how far validation should go with respect to these > values. I see. Not sure what to do about that. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From julian.reschke@gmx.de Mon Aug 9 12:39:55 2010 Return-Path: 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 D69953A6B39 for ; Mon, 9 Aug 2010 12:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.36 X-Spam-Level: X-Spam-Status: No, score=-103.36 tagged_above=-999 required=5 tests=[AWL=-0.761, 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 Mq+ppjA97Wp1 for ; Mon, 9 Aug 2010 12:39:53 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id 64C693A6B2B for ; Mon, 9 Aug 2010 12:39:51 -0700 (PDT) Received: (qmail invoked by alias); 09 Aug 2010 19:40:21 -0000 Received: from p508FE3AB.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.227.171] by mail.gmx.net (mp044) with SMTP; 09 Aug 2010 21:40:21 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+J4kYviLWJrkIvHifRPrsJdKVFBNr2fanbYBIt0O Y9ChSQEmaLcqhH Message-ID: <4C6059A1.3000802@gmx.de> Date: Mon, 09 Aug 2010 21:40:17 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Ian Hickson References: <4C5FA78D.80108@gmx.de> <4C5FCC51.60108@gmx.de> <4C604A01.8060604@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: link-relations@ietf.org Subject: Re: [link-relations] NEW APP DATA X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 19:39:56 -0000 On 09.08.2010 21:10, Ian Hickson wrote: > ... >> Maybe it's just me, but I don't think it was designed for that. > > Well, the field registry exists so as to make it possible to use the > registry for HTML, as I understand it. But maybe I'm mistaken, and we're > not supposed to use the registry for HTML relations? I'm confused now. > ... Yes, we want a registry that can be shared among HTML, Atom, HTTP, and other users of link relations. But that doesn't necessarily imply that a specific application needs to off-load everything it wants into that registry. > ... >>> Ok... Do I have to convince you for the fields to be registered? >> >> There are three designated experts, and I assume you need to convince at >> least one of them. I'm one of those. > > I see. > > How can I convince you? > ... 1) You could re-consider the default ("not valid"). 2) You could rephrase the application flags in a more generic way (as discussed last November). ..also, in the HTML WG, we really need to discuss whether conformance checkers ought to check link relations. > ... >> My understanding is that we want *future* registered link relations to >> be broadly usable. So for the example you just mentioned I don't see how >> a registration would suceed. > > Well it would be a pretty useless registry if it didn't match reality. :-) > I would presume that if someone implemented such a value, getting it > registered would be near-automatic, since otherwise we're just going to > end up with clashes because people won't be able to register the values > they're using, no? > ... If someone tried to register that relation, I'd probably propose to use an extension relation type instead, or to prefix the short name with something that makes it clear it's very application-specific. So, no, there is no automatism. >>>> Are you confident that and always have the same >>>> requirements? >>> >>> They currently do. If that changes, we'll update the registries. Who >>> knows what the future holds. >> >> And add yet another column to the generic registry? > > Are columns expensive? Yes, because it makes all future registrations more complicated. I'd expect new columns to be an exception. Mark? >> The point being it's only meaningless (in HTML) when it's the *only* >> link relation on the link. Thus, it doesn't make sense to forbid >> >> > >> just because >> >> > >> might be an authoring mistake. > > That's possible, but that's an issue for HTML, not for the registry, no? Yes, the registry should just allow "noreferrer". That's my point. >>>>> Regarding the final parenthetical, I believe the templates fit >>>>> what is described in the Web Linking spec. >>>> >>>> It does, this is an oversight in the spec. So we'd have to figure >>>> out unique names upon registration. >>> >>> I'm just trying to do what the spec says here. >> >> In the meantime, what's your take on the part of my email you skipped? > >> Going back to the original issue (hopefully providing context for >> those who weren't there): we discussed application-specific data >> when we met in Santa Clara last November. The use case that was >> provided was a flag that would allow user agents to decide what kind >> of links need to be followed when going offline or archiving a >> resource. That makes a lot of sense, and I'd support that kind of >> flag, hopefully described in a way that isn't totally specific to >> HTML. > > I have no opinion on this. Well, it's the use case you brought up (as far as I recall), and why the application data registry was added. I think it's a good use case, and I expected that this would be the application data you're going to register. >> What you are proposing is much more; it augments the link type >> registry with validation hints. I'm totally unconvinced that this is >> a good idea; in particular given the fact that it's an open question >> in the HTML WG how far validation should go with respect to these >> values. > > I see. Not sure what to do about that. One approach would be to simplify the application data as described above, and consider the remainder (if needed at all) something local to HTML. Best regards, Julian From ian@hixie.ch Mon Aug 9 14:47:00 2010 Return-Path: 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 983503A68D9 for ; Mon, 9 Aug 2010 14:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599] 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 H-RYCr-9KJSt for ; Mon, 9 Aug 2010 14:46:55 -0700 (PDT) Received: from homiemail-a49.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id A31593A6878 for ; Mon, 9 Aug 2010 14:46:55 -0700 (PDT) Received: from homiemail-a49.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTP id A1A155E0069; Mon, 9 Aug 2010 14:47:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=hixie.ch; h=date:from:to:cc :subject:in-reply-to:message-id:references:mime-version: content-type; q=dns; s=hixie.ch; b=dVtMvtih9ANOp+lajrV2wUrjw6JEh 0bzVZq3FaF3X35Wo1PerCR4HyX/ogTLtysTGwxFElOXpl0nCcS2KI7kjnD0Zk+iN gC0gxOgLE1b3AvdKl1wEuKNFj2cFzhTCbhcyEP79JULKLRqJmWZA0C2sdiceaVFj bD8B2Ke2fFDg5k= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hixie.ch; h=date:from:to :cc:subject:in-reply-to:message-id:references:mime-version: content-type; s=hixie.ch; bh=5wlurwpKkmkE74BziV893w8be+o=; b=Nbm S3wfr2YLp3RSCHFL+1luUQndjSshbzYvPDS1tifDTInVgyzreJDUp4UcUflUeY/7 Vu/qn1HX7flj+xiQeG0XCSvYqz4LwX6uZjjy8+7mqMKrAOBWDFFlEyPLj9oMYx7P eeNiWxEfl/ndYjmVdx2FtpYz4cdKBIVGoHUt/awY= Received: from ps20323.dreamhostps.com (ps20323.dreamhost.com [69.163.222.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: internal@index.hixie.ch) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTPSA id 92EEB5E005F; Mon, 9 Aug 2010 14:47:29 -0700 (PDT) Date: Mon, 9 Aug 2010 21:47:29 +0000 (UTC) From: Ian Hickson To: Julian Reschke In-Reply-To: <4C6059A1.3000802@gmx.de> Message-ID: References: <4C5FA78D.80108@gmx.de> <4C5FCC51.60108@gmx.de> <4C604A01.8060604@gmx.de> <4C6059A1.3000802@gmx.de> Content-Language: en-GB-hixie Content-Style-Type: text/css MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: link-relations@ietf.org Subject: Re: [link-relations] NEW APP DATA X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 21:47:00 -0000 On Mon, 9 Aug 2010, Julian Reschke wrote: > On 09.08.2010 21:10, Ian Hickson wrote: > > > > > > Maybe it's just me, but I don't think it was designed for that. > > > > Well, the field registry exists so as to make it possible to use the > > registry for HTML, as I understand it. But maybe I'm mistaken, and > > we're not supposed to use the registry for HTML relations? I'm > > confused now. > > Yes, we want a registry that can be shared among HTML, Atom, HTTP, and > other users of link relations. > > But that doesn't necessarily imply that a specific application needs to > off-load everything it wants into that registry. It's unclear to me how I am supposed to use the registry then. > > > > Ok... Do I have to convince you for the fields to be registered? > > > > > > There are three designated experts, and I assume you need to > > > convince at least one of them. I'm one of those. > > > > How can I convince you? > > 1) You could re-consider the default ("not valid"). The default only applies to the existing relations, right? I didn't really want to pick a default at all, I just wanted to list the values for the keywords I was familiar with, and wanted to let the people who'd registered the other values determine the values if they wanted their keywords usable with HTML. I'm happy to change the "default" to something else and just list the values differently, but that just seems like busywork, it wouldn't actually change anything in the registry. > 2) You could rephrase the application flags in a more generic way (as > discussed last November). It's unclear what this would mean. I don't think making things "generic" makes sense here. We're trying to solve a very specific problem for this application (HTML), for which we need specific data... how would we make this generic? > ..also, in the HTML WG, we really need to discuss whether conformance > checkers ought to check link relations. That seems out of scope for this particular thread. > > > My understanding is that we want *future* registered link relations > > > to be broadly usable. So for the example you just mentioned I don't > > > see how a registration would suceed. > > > > Well it would be a pretty useless registry if it didn't match reality. > > :-) I would presume that if someone implemented such a value, getting > > it registered would be near-automatic, since otherwise we're just > > going to end up with clashes because people won't be able to register > > the values they're using, no? > > If someone tried to register that relation, I'd probably propose to use > an extension relation type instead, or to prefix the short name with > something that makes it clear it's very application-specific. Ok well that seems somewhat off-topic for this registration so I guess we should leave this for another thread. > > > The point being it's only meaningless (in HTML) when it's the *only* > > > link relation on the link. Thus, it doesn't make sense to forbid > > > > > > > > > > > just because > > > > > > > > > > > might be an authoring mistake. > > > > That's possible, but that's an issue for HTML, not for the registry, > > no? > > Yes, the registry should just allow "noreferrer". That's my point. Surely we don't want to update HTML each time there's a change to the registry? Or is that what you're saying we should do? I don't understand. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From julian.reschke@gmx.de Mon Aug 9 23:48:32 2010 Return-Path: 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 651ED3A6A2E for ; Mon, 9 Aug 2010 23:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.338 X-Spam-Level: X-Spam-Status: No, score=-103.338 tagged_above=-999 required=5 tests=[AWL=-0.739, 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 DQznCghw3134 for ; Mon, 9 Aug 2010 23:48:30 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id D81BA3A690F for ; Mon, 9 Aug 2010 23:48:29 -0700 (PDT) Received: (qmail invoked by alias); 10 Aug 2010 06:49:01 -0000 Received: from p508FE025.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.224.37] by mail.gmx.net (mp001) with SMTP; 10 Aug 2010 08:49:01 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/nv3IUoKPnp7H2XdPrDm5HaIVi/GQVynr2sxtgAP HsqkUVhFJ1pEks Message-ID: <4C60F657.6020108@gmx.de> Date: Tue, 10 Aug 2010 08:48:55 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Ian Hickson References: <4C5FA78D.80108@gmx.de> <4C5FCC51.60108@gmx.de> <4C604A01.8060604@gmx.de> <4C6059A1.3000802@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: link-relations@ietf.org Subject: Re: [link-relations] NEW APP DATA X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 06:48:32 -0000 On 09.08.2010 23:47, Ian Hickson wrote: > ... >> Yes, we want a registry that can be shared among HTML, Atom, HTTP, and >> other users of link relations. >> >> But that doesn't necessarily imply that a specific application needs to >> off-load everything it wants into that registry. > > It's unclear to me how I am supposed to use the registry then. > ... Just mentioning the options: one approach would be to have a second place for the additional information, another one would be to reconsider whether the additional information actually makes sense. >>>>> Ok... Do I have to convince you for the fields to be registered? >>>> >>>> There are three designated experts, and I assume you need to >>>> convince at least one of them. I'm one of those. >>> >>> How can I convince you? >> >> 1) You could re-consider the default ("not valid"). > > The default only applies to the existing relations, right? I didn't really > want to pick a default at all, I just wanted to list the values for the > keywords I was familiar with, and wanted to let the people who'd > registered the other values determine the values if they wanted their > keywords usable with HTML. Yes, and again: I do not see why any of those would not be allowed in HTML, so I really think you have chosen the wrong default value. > I'm happy to change the "default" to something else and just list the > values differently, but that just seems like busywork, it wouldn't > actually change anything in the registry. It would change the value the existing registrations get. >> 2) You could rephrase the application flags in a more generic way (as >> discussed last November). > > It's unclear what this would mean. I don't think making things "generic" > makes sense here. We're trying to solve a very specific problem for this > application (HTML), for which we need specific data... how would we make > this generic? I explained that already. Define behavior for user agents (as discussed last year), not HTML-specific validity constraints. > ... >>>> The point being it's only meaningless (in HTML) when it's the *only* >>>> link relation on the link. Thus, it doesn't make sense to forbid >>>> >>>> >>> >>>> just because >>>> >>>> >>> >>>> might be an authoring mistake. >>> >>> That's possible, but that's an issue for HTML, not for the registry, >>> no? >> >> Yes, the registry should just allow "noreferrer". That's my point. > > Surely we don't want to update HTML each time there's a change to the > registry? Or is that what you're saying we should do? I don't understand. What I'm saying is that "noreferrer" should be allowed on / and ; as far as I can tell, your proposal disallows it for (consistent with HTML5, so this is a bug in HTML5), and also disallows it for / (which seems to be a bug in your registration). (There may be more problems, I just checked this one). Best regards, Julian From ian@hixie.ch Tue Aug 10 00:53:13 2010 Return-Path: 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 068E73A6A0A for ; Tue, 10 Aug 2010 00:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599] 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 ZCispmL1-MGc for ; Tue, 10 Aug 2010 00:53:11 -0700 (PDT) Received: from homiemail-a57.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id 9EAD03A6902 for ; Tue, 10 Aug 2010 00:53:11 -0700 (PDT) Received: from homiemail-a57.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a57.g.dreamhost.com (Postfix) with ESMTP id 6F08620806B; Tue, 10 Aug 2010 00:53:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=hixie.ch; h=date:from:to:cc :subject:in-reply-to:message-id:references:mime-version: content-type; q=dns; s=hixie.ch; b=4dn7m1j/ffeMCzUrAWn+AIvgnCW2b 8vFbm98RBAtQDtyCLq0UlGc9Vmfy78tY+MIpk0FHHU1WYcwyEB+8joh9Lxf8P9fH tNv0VvKEUMrlcj84stsM1LiAPUolwkPP6h1Wx5ynyuBwsuzA13PKI/SI3oSj+rlv Y31wXMKZPVKYW4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hixie.ch; h=date:from:to :cc:subject:in-reply-to:message-id:references:mime-version: content-type; s=hixie.ch; bh=4a7qDvKWpDdh89dde+l9iC6slsM=; b=xfB PnBSzD4gOH3LuVhJ4X09v4reqa+EXC3vJjlwhI1InTt8mIfjuRuFI6waFu8X484G V2cMLSfRdQoEi56TMwWoCAkqi+z8gpMJqGOuS6dQZ6nVjkkzVV2XGH6ULAOLEdl1 zNqK3DbLDc6z7YYNIRxyVu/XW4Jwx1CxK7+kUTq8= Received: from ps20323.dreamhostps.com (ps20323.dreamhost.com [69.163.222.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: internal@index.hixie.ch) by homiemail-a57.g.dreamhost.com (Postfix) with ESMTPSA id 6A8CF208063; Tue, 10 Aug 2010 00:53:46 -0700 (PDT) Date: Tue, 10 Aug 2010 07:53:46 +0000 (UTC) From: Ian Hickson To: Julian Reschke In-Reply-To: <4C60F657.6020108@gmx.de> Message-ID: References: <4C5FA78D.80108@gmx.de> <4C5FCC51.60108@gmx.de> <4C604A01.8060604@gmx.de> <4C6059A1.3000802@gmx.de> <4C60F657.6020108@gmx.de> Content-Language: en-GB-hixie Content-Style-Type: text/css MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: link-relations@ietf.org Subject: Re: [link-relations] NEW APP DATA X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 07:53:13 -0000 On Tue, 10 Aug 2010, Julian Reschke wrote: > > > > > > 2) You could rephrase the application flags in a more generic way > > > (as discussed last November). > > > > It's unclear what this would mean. I don't think making things > > "generic" makes sense here. We're trying to solve a very specific > > problem for this application (HTML), for which we need specific > > data... how would we make this generic? > > I explained that already. Define behavior for user agents (as discussed > last year), not HTML-specific validity constraints. The proposal does both. Are you saying I should file separate registrations for whether something is a hyperlink or an external resource link, and whether something is allowed on or /? I suppose we could do that but that would just make the interface with the HTML spec a bit more complicated, and I don't understand how that would help anyone. Are other languages also interested in the distinction between hyperlinks and external resource links? I assumed this was just an HTML issue. > > Surely we don't want to update HTML each time there's a change to the > > registry? Or is that what you're saying we should do? I don't > > understand. > > What I'm saying is that "noreferrer" should be allowed on / and > ; as far as I can tell, your proposal disallows it for > (consistent with HTML5, so this is a bug in HTML5), and also disallows > it for / (which seems to be a bug in your registration). I don't understand how it affects noreferrer. That keyword isn't listed in the registry and isn't in the proposal as far as I can tell. At this point I'm unsure how to proceed. Is the registration request denied? Should I just send the request again but listing the keywords that are not allowed rather than the keywords that are hyperlinks, and with the default switched around? I don't really understand this process. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From julian.reschke@gmx.de Tue Aug 10 01:16:07 2010 Return-Path: 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 E03493A6A7D for ; Tue, 10 Aug 2010 01:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.317 X-Spam-Level: X-Spam-Status: No, score=-103.317 tagged_above=-999 required=5 tests=[AWL=-0.718, 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 R4vyKZC4UQ+g for ; Tue, 10 Aug 2010 01:16:07 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 8C98A3A6A26 for ; Tue, 10 Aug 2010 01:16:06 -0700 (PDT) Received: (qmail invoked by alias); 10 Aug 2010 08:16:38 -0000 Received: from p508FE025.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.224.37] by mail.gmx.net (mp063) with SMTP; 10 Aug 2010 10:16:38 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/vDXcofcTvPRoyibmkCVkfjgkokR2CKjB7Vx0ny4 3QDZA0Achubx5B Message-ID: <4C610AE2.5090306@gmx.de> Date: Tue, 10 Aug 2010 10:16:34 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Ian Hickson References: <4C5FA78D.80108@gmx.de> <4C5FCC51.60108@gmx.de> <4C604A01.8060604@gmx.de> <4C6059A1.3000802@gmx.de> <4C60F657.6020108@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: link-relations@ietf.org Subject: Re: [link-relations] NEW APP DATA X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 08:16:08 -0000 On 10.08.2010 09:53, Ian Hickson wrote: >> I explained that already. Define behavior for user agents (as discussed >> last year), not HTML-specific validity constraints. > > The proposal does both. Are you saying I should file separate > registrations for whether something is a hyperlink or an external resource > link, and whether something is allowed on or/? I suppose > we could do that but that would just make the interface with the HTML spec > a bit more complicated, and I don't understand how that would help anyone. > Are other languages also interested in the distinction between hyperlinks > and external resource links? I assumed this was just an HTML issue. Actually, I'd prefer a single flag for link/external resource (and yes, this may affect other languages as well), and keep the conformance related flags out of the IANA registry (but again, this is just the opinion of one of the D.E.s). >>> Surely we don't want to update HTML each time there's a change to the >>> registry? Or is that what you're saying we should do? I don't >>> understand. >> >> What I'm saying is that "noreferrer" should be allowed on/ and >> ; as far as I can tell, your proposal disallows it for >> (consistent with HTML5, so this is a bug in HTML5), and also disallows >> it for/ (which seems to be a bug in your registration). > > I don't understand how it affects noreferrer. That keyword isn't listed in > the registry and isn't in the proposal as far as I can tell. You are right. Sorry. So, taking another example where the flags are different for and /: why is "bookmark" disallowed on link? > At this point I'm unsure how to proceed. Is the registration request > denied? Should I just send the request again but listing the keywords that > are not allowed rather than the keywords that are hyperlinks, and with the > default switched around? I don't really understand this process. Apparently, we (you and I) are still discussing the registration. Let me summarize again my concerns: - Unconvinced that and require different treatment. - Unconvinced that the IANA registry needs to carry metadata for HTML validation. - Unconvinced that the default of "no" for is right. If somebody defines a link relation, and it doesn't make sense on , then it appears that something is very wrong with the proposed semantics of the link relation. -> Proposal: just define a flag that reflects the "hyperlink"/"external resource" distinction. Best regards, Julian From mnot@mnot.net Tue Aug 10 04:30:56 2010 Return-Path: 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 168013A6912 for ; Tue, 10 Aug 2010 04:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.458 X-Spam-Level: X-Spam-Status: No, score=-105.458 tagged_above=-999 required=5 tests=[AWL=-2.859, 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 sJ-STp6oBDkP for ; Tue, 10 Aug 2010 04:30:54 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id 813F93A6405 for ; Tue, 10 Aug 2010 04:30:53 -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 C367D22E258; Tue, 10 Aug 2010 07:31:21 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <4C610AE2.5090306@gmx.de> Date: Tue, 10 Aug 2010 21:31:27 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <5E49EAB5-081F-40C1-9296-222A526CE78B@mnot.net> References: <4C5FA78D.80108@gmx.de> <4C5FCC51.60108@gmx.de> <4C604A01.8060604@gmx.de> <4C6059A1.3000802@gmx.de> <4C60F657.6020108@gmx.de> <4C610AE2.5090306@gmx.de> To: "Julian F. Reschke" , Ian Hickson X-Mailer: Apple Mail (2.1081) Cc: link-relations@ietf.org Subject: Re: [link-relations] NEW APP DATA X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 11:30:56 -0000 Gentlemen, My (possibly and perhaps mercifully uninformed) view is that the issues = you're discussing are specific to HTML5, and should be decided in the = appropriate venue before bringing this forward for registration; the = link relations registry is relatively neutral about how and for what the = appdata fields are used for.=20 There's another aspect of this that I have concerns about process-wise, = which I'll raise in a separate e-mail. I will say that appdata fields are expensive in the sense that once = they're added, they persist. So, we need to make sure that this is how = they'll actually be specified before they're added to the registry. This = is why adding new appdata fields is Specification Required, which = implies permanence.=20 Regards, P.S. Ian - when you do register something, convention dictates that the = template (which you've pasted below) actually go in the document itself. On 10/08/2010, at 6:16 PM, Julian Reschke wrote: > On 10.08.2010 09:53, Ian Hickson wrote: >>> I explained that already. Define behavior for user agents (as = discussed >>> last year), not HTML-specific validity constraints. >>=20 >> The proposal does both. Are you saying I should file separate >> registrations for whether something is a hyperlink or an external = resource >> link, and whether something is allowed on or/? I = suppose >> we could do that but that would just make the interface with the HTML = spec >> a bit more complicated, and I don't understand how that would help = anyone. >> Are other languages also interested in the distinction between = hyperlinks >> and external resource links? I assumed this was just an HTML issue. >=20 > Actually, I'd prefer a single flag for link/external resource (and = yes, this may affect other languages as well), and keep the conformance = related flags out of the IANA registry (but again, this is just the = opinion of one of the D.E.s). >=20 >>>> Surely we don't want to update HTML each time there's a change to = the >>>> registry? Or is that what you're saying we should do? I don't >>>> understand. >>>=20 >>> What I'm saying is that "noreferrer" should be allowed on/ = and >>> ; as far as I can tell, your proposal disallows it for >>> (consistent with HTML5, so this is a bug in HTML5), and also = disallows >>> it for/ (which seems to be a bug in your registration). >>=20 >> I don't understand how it affects noreferrer. That keyword isn't = listed in >> the registry and isn't in the proposal as far as I can tell. >=20 > You are right. Sorry. >=20 > So, taking another example where the flags are different for = and /: why is "bookmark" disallowed on link? >=20 >> At this point I'm unsure how to proceed. Is the registration request >> denied? Should I just send the request again but listing the keywords = that >> are not allowed rather than the keywords that are hyperlinks, and = with the >> default switched around? I don't really understand this process. >=20 > Apparently, we (you and I) are still discussing the registration. >=20 > Let me summarize again my concerns: >=20 > - Unconvinced that and require different treatment. >=20 > - Unconvinced that the IANA registry needs to carry metadata for HTML = validation. >=20 > - Unconvinced that the default of "no" for is right. If = somebody defines a link relation, and it doesn't make sense on , = then it appears that something is very wrong with the proposed semantics = of the link relation. >=20 > -> Proposal: just define a flag that reflects the = "hyperlink"/"external resource" distinction. >=20 > Best regards, Julian >=20 > _______________________________________________ > link-relations mailing list > link-relations@ietf.org > https://www.ietf.org/mailman/listinfo/link-relations -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Tue Aug 10 04:31:01 2010 Return-Path: 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 2B1BC3A693E for ; Tue, 10 Aug 2010 04:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.906 X-Spam-Level: X-Spam-Status: No, score=-104.906 tagged_above=-999 required=5 tests=[AWL=-3.207, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, MIME_8BIT_HEADER=0.3, 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 wxr5PO1+vzfU for ; Tue, 10 Aug 2010 04:31:00 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id 0168A3A6912 for ; Tue, 10 Aug 2010 04:31:00 -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 5F3BC22E1F3; Tue, 10 Aug 2010 07:31:29 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: Date: Tue, 10 Aug 2010 21:31:38 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <9CDE7636-3E12-48AA-A351-FDD432112978@mnot.net> References: To: =?iso-8859-1?Q?Philippe_Le_H=E9garet?= , Thomas Roessler , Ian Hickson X-Mailer: Apple Mail (2.1081) Cc: link-relations@ietf.org Subject: Re: [link-relations] NEW APP DATA X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 11:31:01 -0000 Hi Ian, This registration is a bit unusual, in that you're registering using = whatwg.org URIs, when the W3C -- an organisation that the IETF = recognises as producing Open Standards --- as per RFC2026 -- is = producing a specification that is substantially the same. While whatwg.org isn't necessarily precluded from meeting the = prerequisites of Specification Required (and therefore making = registrations), we want to make sure that this isn't conflicting with = ongoing W3C work. As such I've CC:ed the W3C's liaisons to the IETF for their comment.=20 Philippe and Thomas: this is a registration request for new app data = fields in the link relation registry, established by = . = In particular, I'm looking for a statement of whether this conflicts = with current W3C work, represents W3C consensus, etc.=20 Regards, On 09/08/2010, at 2:30 PM, Ian Hickson wrote: >=20 > o Application Name: HTML > o Description: Effect on a and area elements > o Default Value: Not allowed > o Notes: The following values should have "Hyperlink" for this > field: alternate, appendix, bookmark, chapter, contents, > copyright, first, glossary, help, index, first, last, license, > next, prev, previous, section, start, subsection, up. > o Specification: = http://www.whatwg.org/specs/web-apps/current-work/complete.html#iana-regis= try >=20 > o Application Name: HTML > o Description: Effect on link elements > o Default Value: Not allowed > o Notes: The following values should have "Hyperlink" for this > field: alternate, appendix, chapter, contents, copyright, > first, glossary, help, index, first, last, license, next, > prev, previous, section, start, subsection, up. The following > values should have "External Resource Link" for this field: > stylesheet. > o Specification: = http://www.whatwg.org/specs/web-apps/current-work/complete.html#iana-regis= try >=20 > --=20 > Ian Hickson U+1047E )\._.,--....,'``. = fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ = ,. > Things that are impossible just take longer. = `._.-(,_..'--(,_..'`-.;.' > _______________________________________________ > link-relations mailing list > link-relations@ietf.org > https://www.ietf.org/mailman/listinfo/link-relations -- Mark Nottingham http://www.mnot.net/ From plh@w3.org Tue Aug 10 09:54:44 2010 Return-Path: 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 828B53A684B for ; Tue, 10 Aug 2010 09:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.37 X-Spam-Level: X-Spam-Status: No, score=-9.37 tagged_above=-999 required=5 tests=[AWL=0.630, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-8] 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 XeZsWIPzWu4v for ; Tue, 10 Aug 2010 09:54:43 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by core3.amsl.com (Postfix) with ESMTP id 628EF3A6833 for ; Tue, 10 Aug 2010 09:54:43 -0700 (PDT) Received: from 30-7-253.wireless.csail.mit.edu ([128.30.7.253]) by jay.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Ois6d-0001tl-ML; Tue, 10 Aug 2010 12:55:15 -0400 From: Philippe Le Hegaret To: Mark Nottingham In-Reply-To: <9CDE7636-3E12-48AA-A351-FDD432112978@mnot.net> References: <9CDE7636-3E12-48AA-A351-FDD432112978@mnot.net> Content-Type: text/plain; charset="UTF-8" Organization: World Wide Web Consortium Date: Tue, 10 Aug 2010 12:55:15 -0400 Message-ID: <1281459315.701.260.camel@chacal> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 10 Aug 2010 10:11:46 -0700 Cc: Ian Hickson , Thomas Roessler , link-relations@ietf.org Subject: Re: [link-relations] NEW APP DATA X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 16:54:44 -0000 On Tue, 2010-08-10 at 21:31 +1000, Mark Nottingham wrote: > Hi Ian, > > This registration is a bit unusual, in that you're registering using whatwg.org URIs, when the W3C -- an organisation that the IETF recognises as producing Open Standards --- as per RFC2026 -- is producing a specification that is substantially the same. > > While whatwg.org isn't necessarily precluded from meeting the prerequisites of Specification Required (and therefore making registrations), we want to make sure that this isn't conflicting with ongoing W3C work. > > As such I've CC:ed the W3C's liaisons to the IETF for their comment. > > Philippe and Thomas: this is a registration request for new app data fields in the link relation registry, established by . In particular, I'm looking for a statement of whether this conflicts with current W3C work, represents W3C consensus, etc. I see no reason here why the registration cannot point to the W3C specification. The W3C HTML Working Group is producing the specification for HTML, and pointing to somewhere would undermine the current process and effort happening within W3C. Ian, is there a reason why it isn't the case? Philippe From ian@hixie.ch Tue Aug 10 11:01:17 2010 Return-Path: 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 4CE5E3A6827 for ; Tue, 10 Aug 2010 11:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599] 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 I3LAJAr49N7C for ; Tue, 10 Aug 2010 11:01:15 -0700 (PDT) Received: from homiemail-a43.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id 97E4B3A6A99 for ; Tue, 10 Aug 2010 11:01:15 -0700 (PDT) Received: from homiemail-a43.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a43.g.dreamhost.com (Postfix) with ESMTP id 7FCDE8C06B for ; Tue, 10 Aug 2010 11:01:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=hixie.ch; h=date:from:to:subject :in-reply-to:message-id:references:mime-version:content-type; q= dns; s=hixie.ch; b=tFFFQjE+tfG8N66ZRC0qUMy+uAgVKOTLW0Pnh33iRRXjH 51nMupwKYfDXICqFcu+3Tuwl5OL5RSZba0syyP7SOesE+737j9/sBBS35gvstx/d PUBlOJGnnEaTqlFcfJLOLpXA0MxyHnxgJNaViYAea/FsbZwKUQX+EcM54HycMk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hixie.ch; h=date:from:to :subject:in-reply-to:message-id:references:mime-version: content-type; s=hixie.ch; bh=CfhJGhwsKfM2EjltVOtvLHFFadY=; b=MRF 1dED5TdJlqQsF1a71qkGsWCOWeYDAywtQgudJXTBSF30ExcfFFK+ojNOnOcbUxuj M8Hd5W0sifiRJXiz+mcPbFVkMY53rTn+GfkJ8wICWWeEcvLWb9LXH5Rt7/49j8dY nDy64w1iRufNTtRy8gPakVqQ235lZbXAaoWffQ3g= Received: from ps20323.dreamhostps.com (ps20323.dreamhost.com [69.163.222.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: internal@index.hixie.ch) by homiemail-a43.g.dreamhost.com (Postfix) with ESMTPSA id 7C9358C06A for ; Tue, 10 Aug 2010 11:01:50 -0700 (PDT) Date: Tue, 10 Aug 2010 18:01:50 +0000 (UTC) From: Ian Hickson To: link-relations@ietf.org In-Reply-To: <1281459315.701.260.camel@chacal> Message-ID: References: <9CDE7636-3E12-48AA-A351-FDD432112978@mnot.net> <1281459315.701.260.camel@chacal> Content-Language: en-GB-hixie Content-Style-Type: text/css MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [link-relations] NEW APP DATA X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 18:01:17 -0000 On Tue, 10 Aug 2010, Julian Reschke wrote: > On 10.08.2010 09:53, Ian Hickson wrote: > > > I explained that already. Define behavior for user agents (as > > > discussed last year), not HTML-specific validity constraints. > > > > The proposal does both. Are you saying I should file separate > > registrations for whether something is a hyperlink or an external > > resource link, and whether something is allowed on or/? > > I suppose we could do that but that would just make the interface with > > the HTML spec a bit more complicated, and I don't understand how that > > would help anyone. Are other languages also interested in the > > distinction between hyperlinks and external resource links? I assumed > > this was just an HTML issue. > > Actually, I'd prefer a single flag for link/external resource (and yes, > this may affect other languages as well), and keep the conformance > related flags out of the IANA registry (but again, this is just the > opinion of one of the D.E.s). I see. > So, taking another example where the flags are different for and > /: why is "bookmark" disallowed on link? Because it wouldn't make any sense on as defined. This is why conformance is an inherent part of the keywords. In fact, I am surprised other uses of these keywords don't have the same problem. For example, if we added "bookmark" (replacing the current registration which doesn't match real world usage of the keyword) to the registry, then a user agent would be unable to properly process it in an Atom environment or when used with a Link: header. > - Unconvinced that and require different treatment. The simplest example of this is rel=stylesheet. > - Unconvinced that the IANA registry needs to carry metadata for HTML > validation. It certainly would be inconvenient if the HTML spec had to use two registries. > - Unconvinced that the default of "no" for is right. If somebody > defines a link relation, and it doesn't make sense on , then it appears > that something is very wrong with the proposed semantics of the link relation. There are very few where this is the case, but I don't see why that would mean a relation where this is the case is wrong. > -> Proposal: just define a flag that reflects the "hyperlink"/"external > resource" distinction. I'll have to think about this. It's unclear to me that this would be the most convenient mechanism. On Tue, 10 Aug 2010, Mark Nottingham wrote: > > My (possibly and perhaps mercifully uninformed) view is that the issues > you're discussing are specific to HTML5, and should be decided in the > appropriate venue before bringing this forward for registration; the > link relations registry is relatively neutral about how and for what the > appdata fields are used for. The issues had in fact been decided in an appropriate venue; I was surprised to find any resistance in the registration. > I will say that appdata fields are expensive in the sense that once > they're added, they persist. So, we need to make sure that this is how > they'll actually be specified before they're added to the registry. This > is why adding new appdata fields is Specification Required, which > implies permanence. Sure. > P.S. Ian - when you do register something, convention dictates that the > template (which you've pasted below) actually go in the document itself. Ah, ok. This is unclear in the registry's specification, which says to mail the template to the list. On Tue, 10 Aug 2010, Mark Nottingham wrote: > > This registration is a bit unusual, in that you're registering using > whatwg.org URIs, when the W3C -- an organisation that the IETF > recognises as producing Open Standards --- as per RFC2026 -- is > producing a specification that is substantially the same. > > While whatwg.org isn't necessarily precluded from meeting the > prerequisites of Specification Required (and therefore making > registrations), we want to make sure that this isn't conflicting with > ongoing W3C work. On Tue, 10 Aug 2010, Philippe Le Hegaret wrote: > > I see no reason here why the registration cannot point to the W3C > specification. The W3C HTML Working Group is producing the specification > for HTML, and pointing to somewhere would undermine the current process > and effort happening within W3C. > > Ian, is there a reason why it isn't the case? The WHATWG is also producing the specification for HTML, so by that line of argument, pointing to somewhere other than the WHATWG would also undermine the current process and effort happening within the WHATWG. But that's clearly nonsense. It doesn't make the slightest difference to ongoing work what the URLs are. :-) I used the WHATWG URLs because the W3C doesn't publish a version of the "complete.html" file that I used in the registration, and because the WHATWG documents are generally more convenient to work with than the W3C ones (e.g. it has bug filing tools, nicer styling, etc). Also, the WHATWG URLs are more stable than the W3C ones at this point (the W3C keeps taking things out, splitting the specs into other specs, etc), and I didn't want to have to keep updating the registration. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian@hixie.ch Tue Aug 10 11:16:41 2010 Return-Path: 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 C1FEC3A699A for ; Tue, 10 Aug 2010 11:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.438 X-Spam-Level: X-Spam-Status: No, score=-1.438 tagged_above=-999 required=5 tests=[AWL=-0.916, BAYES_00=-2.599, SUBJ_ALL_CAPS=2.077] 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 dm+FXvbdLMz3 for ; Tue, 10 Aug 2010 11:16:40 -0700 (PDT) Received: from homiemail-a53.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id E45B53A6827 for ; Tue, 10 Aug 2010 11:16:39 -0700 (PDT) Received: from homiemail-a53.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a53.g.dreamhost.com (Postfix) with ESMTP id 0FE3213806A for ; Tue, 10 Aug 2010 11:17:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=hixie.ch; h=date:from:to:subject :message-id:mime-version:content-type; q=dns; s=hixie.ch; b=nDSV aDxMupgLO+Dm4fr37i7pS3sCQxAeGOvghEjHMcgr44p3+zENuijssMyQ5z14Brw7 zyimWqXhQhClLrOux09/mAVy8T7vr5DDB8f5W2TEBqYxjJGdU0ep7d6pnRYCkyma d8LQil9AnARH70vBcln/pWLOhkkpatIfyoq4dc8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hixie.ch; h=date:from:to :subject:message-id:mime-version:content-type; s=hixie.ch; bh=6m vmLDjQdZqqCizPByPW7nWP2FY=; b=QEEJk+aHvgfBko9aEL2tpqYoC+rh7y4FBt 4E7wD7uRcRITLtG0N5Vy7wCNT5Dyaio13ukqmZxPZ+xzFqw9nRA6PgcyV9zs7DRt BZsYyvXbSwAhMubBqzUbb1ZThbAqHC5CNj3fzuoQ895ybuMbM8IBdXIHjSZM9mxM qza16vsLc= Received: from ps20323.dreamhostps.com (ps20323.dreamhost.com [69.163.222.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: internal@index.hixie.ch) by homiemail-a53.g.dreamhost.com (Postfix) with ESMTPSA id E8DC2138069 for ; Tue, 10 Aug 2010 11:17:14 -0700 (PDT) Date: Tue, 10 Aug 2010 18:17:14 +0000 (UTC) From: Ian Hickson To: link-relations@ietf.org Message-ID: Content-Language: en-GB-hixie Content-Style-Type: text/css MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [link-relations] NEW RELATION REQUEST X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 18:16:41 -0000 The template for this relation is in the specification as requested: http://www.whatwg.org/specs/web-apps/current-work/complete.html#rel-alternate-registration Thanks, -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian@hixie.ch Tue Aug 10 11:50:32 2010 Return-Path: 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 345383A6AB1 for ; Tue, 10 Aug 2010 11:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599] 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 fPDQXg0ukMEL for ; Tue, 10 Aug 2010 11:50:31 -0700 (PDT) Received: from homiemail-a57.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id 163B73A6AAB for ; Tue, 10 Aug 2010 11:50:31 -0700 (PDT) Received: from homiemail-a57.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a57.g.dreamhost.com (Postfix) with ESMTP id 383C9208065 for ; Tue, 10 Aug 2010 11:51:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=hixie.ch; h=date:from:to:subject :in-reply-to:message-id:references:mime-version:content-type; q= dns; s=hixie.ch; b=l98/Wq28jwNtBYJzzYok4rSbhtPoiQpNwsTsAdmp3mqh/ iAnG/Uo2gtDreFBsJE7BsUcPEFie/BcAo/7MDqXIdR/jaxwv+v1tX+eYB8jqq8B9 pR7GQrXtX1jfMjiOxhvUqcOfAWtiZEJqrvbkD3DXaj9ZVktKC+W+8dgK/NhNKM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hixie.ch; h=date:from:to :subject:in-reply-to:message-id:references:mime-version: content-type; s=hixie.ch; bh=LIno7Dp/S8no2yCkMTL44O4P9c0=; b=ODp fSKFODWYHYoZpzzNuveYahWrbIi0O7jAnUrbYPvNhoryYv5MHoemXeI7ih8iigBF hFy74pAAR4vi13s5yTV/cKddXWsw9ECs4D/YxLnsaTOaaWEIDhQmjgIlIpRi+eEB V2wKvwkmlMbDfwqrYezZzu3xVdYCWgdelonH/sjM= Received: from ps20323.dreamhostps.com (ps20323.dreamhost.com [69.163.222.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: internal@index.hixie.ch) by homiemail-a57.g.dreamhost.com (Postfix) with ESMTPSA id 35569208063 for ; Tue, 10 Aug 2010 11:51:06 -0700 (PDT) Date: Tue, 10 Aug 2010 18:51:06 +0000 (UTC) From: Ian Hickson To: link-relations@ietf.org In-Reply-To: Message-ID: References: <9CDE7636-3E12-48AA-A351-FDD432112978@mnot.net> <1281459315.701.260.camel@chacal> Content-Language: en-GB-hixie Content-Style-Type: text/css MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [link-relations] NEW APP DATA X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 18:50:32 -0000 On Tue, 10 Aug 2010, Ian Hickson wrote: > > [...] ones (e.g. it has bug filing tools, nicer styling, etc). [...] (And possibly most important of all, a more liberal copyright license, which is especially important here since the whole point of this registration is to allow people to use these definitions, which might include copying them into other specs, documentation, or software.) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From julian.reschke@gmx.de Tue Aug 10 12:03:57 2010 Return-Path: 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 B071E3A68CF for ; Tue, 10 Aug 2010 12:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.298 X-Spam-Level: X-Spam-Status: No, score=-103.298 tagged_above=-999 required=5 tests=[AWL=-0.699, 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 nt3idOFBP8xS for ; Tue, 10 Aug 2010 12:03:55 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 8058A3A686D for ; Tue, 10 Aug 2010 12:03:53 -0700 (PDT) Received: (qmail invoked by alias); 10 Aug 2010 19:04:27 -0000 Received: from p508FE025.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.224.37] by mail.gmx.net (mp069) with SMTP; 10 Aug 2010 21:04:27 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/ciJBMForcUDp0uabOvhaf46r/bVBskTKV7b4Y1+ WzL7EaiREcbPX/ Message-ID: <4C61A2B5.7080508@gmx.de> Date: Tue, 10 Aug 2010 21:04:21 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Ian Hickson References: <9CDE7636-3E12-48AA-A351-FDD432112978@mnot.net> <1281459315.701.260.camel@chacal> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: link-relations@ietf.org Subject: Re: [link-relations] NEW APP DATA X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 19:03:57 -0000 On 10.08.2010 20:51, Ian Hickson wrote: > On Tue, 10 Aug 2010, Ian Hickson wrote: >> >> [...] ones (e.g. it has bug filing tools, nicer styling, etc). [...] > > (And possibly most important of all, a more liberal copyright license, > which is especially important here since the whole point of this > registration is to allow people to use these definitions, which might > include copying them into other specs, documentation, or software.) What's wrong with the BSD license used in ? Best regards, Julian From julian.reschke@gmx.de Tue Aug 10 12:11:56 2010 Return-Path: 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 8AA373A6840 for ; Tue, 10 Aug 2010 12:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.28 X-Spam-Level: X-Spam-Status: No, score=-103.28 tagged_above=-999 required=5 tests=[AWL=-0.681, 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 lv-CfyeXawuM for ; Tue, 10 Aug 2010 12:11:54 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 01FD53A67B3 for ; Tue, 10 Aug 2010 12:11:53 -0700 (PDT) Received: (qmail invoked by alias); 10 Aug 2010 19:12:28 -0000 Received: from p508FE025.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.224.37] by mail.gmx.net (mp017) with SMTP; 10 Aug 2010 21:12:28 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18cmS4mKxocvYbvFxIzR6YVXb3DtPUoEi7ppFX/9F YmKKrt5ySLBwFl Message-ID: <4C61A497.8080106@gmx.de> Date: Tue, 10 Aug 2010 21:12:23 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Ian Hickson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Philippe Le Hegaret , link-relations@ietf.org Subject: Re: [link-relations] NEW RELATION REQUEST X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 19:11:56 -0000 On 10.08.2010 20:17, Ian Hickson wrote: > > The template for this relation is in the specification as requested: > > http://www.whatwg.org/specs/web-apps/current-work/complete.html#rel-alternate-registration (beware - do not open with performance challenged UAs such as FF 3.x :-) This actually is an update for an existing registration. Looking at the text from HTML4 and the current text I do not see a problem with the update. That being said, as the original registration refers to an W3C spec, I'd expect the update to do so as well. Best regards, Julian From julian.reschke@gmx.de Tue Aug 10 12:27:23 2010 Return-Path: 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 827BA3A6940 for ; Tue, 10 Aug 2010 12:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.262 X-Spam-Level: X-Spam-Status: No, score=-103.262 tagged_above=-999 required=5 tests=[AWL=-0.663, 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 I60Kztf4Rj5z for ; Tue, 10 Aug 2010 12:27:22 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id E8DB93A67F2 for ; Tue, 10 Aug 2010 12:27:21 -0700 (PDT) Received: (qmail invoked by alias); 10 Aug 2010 19:27:54 -0000 Received: from p508FE025.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.224.37] by mail.gmx.net (mp018) with SMTP; 10 Aug 2010 21:27:54 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/sQy9b4bDsg/GUBPR5SJN1fcigZgBTPfolGOMkCD RVMx8X85uDXGOB Message-ID: <4C61A834.40803@gmx.de> Date: Tue, 10 Aug 2010 21:27:48 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Ian Hickson References: <9CDE7636-3E12-48AA-A351-FDD432112978@mnot.net> <1281459315.701.260.camel@chacal> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: link-relations@ietf.org Subject: [link-relations] app data wrt HTML usage, was: NEW APP DATA X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 19:27:23 -0000 On 10.08.2010 20:01, Ian Hickson wrote: > ... >> So, taking another example where the flags are different for and >> /: why is "bookmark" disallowed on link? > > Because it wouldn't make any sense on as defined. This is why > conformance is an inherent part of the keywords. In fact, I am surprised > other uses of these keywords don't have the same problem. For example, if > we added "bookmark" (replacing the current registration which doesn't > match real world usage of the keyword) to the registry, then a user agent > would be unable to properly process it in an Atom environment or when used > with a Link: header. So maybe the "new" definition is simply incorrect. Why did you change it? >> - Unconvinced that and require different treatment. > > The simplest example of this is rel=stylesheet. That seems rather arbitrary, of course semantics for a/@rel=stylesheet *could* be defined (scoped CSS comes to mind). >> - Unconvinced that the IANA registry needs to carry metadata for HTML >> validation. > > It certainly would be inconvenient if the HTML spec had to use two > registries. As Mark noted, we probably should discuss whether use of relation types should affect document validity over in the HTML WG. >> - Unconvinced that the default of "no" for is right. If somebody >> defines a link relation, and it doesn't make sense on, then it appears >> that something is very wrong with the proposed semantics of the link relation. > > There are very few where this is the case, but I don't see why that would > mean a relation where this is the case is wrong. If there are few, then this implies the default should not be "no". That being said, I don't see anything in the definition of which makes it different from what the HTTP Link header, for instance, defines. Maybe you could elaborate? > ... >> On Tue, 10 Aug 2010, Mark Nottingham wrote: >> >> My (possibly and perhaps mercifully uninformed) view is that the issues >> you're discussing are specific to HTML5, and should be decided in the >> appropriate venue before bringing this forward for registration; the >> link relations registry is relatively neutral about how and for what the >> appdata fields are used for. > > The issues had in fact been decided in an appropriate venue; I was > surprised to find any resistance in the registration. There was no conscious decision. As a matter of fact, there's a related bug (), which hasn't been processed yet. > ... > But that's clearly nonsense. It doesn't make the slightest difference to > ongoing work what the URLs are. :-) > > I used the WHATWG URLs because the W3C doesn't publish a version of the > "complete.html" file that I used in the registration, and because the > ... ...but another one, which is "less complete", but happens to reflect the W3C's view of what HTML5 is... (you know that, I know that, but maybe some people looking at this thread do not) > ... > WHATWG documents are generally more convenient to work with than the W3C > ones (e.g. it has bug filing tools, nicer styling, etc). Also, the WHATWG > ... But they are a pain to use in certain browsers due to their sheer size, and the scripts that are running upon load. (I'm even going to say that sending out these URIs almost is a DOS attack on some people's browsers). > URLs are more stable than the W3C ones at this point (the W3C keeps taking > things out, splitting the specs into other specs, etc), and I didn't want > to have to keep updating the registration. That's why we'd want the links to point at a published draft, not at work-in-progress. Best regards, Julian From plh@w3.org Tue Aug 10 12:12:32 2010 Return-Path: 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 05E873A686D for ; Tue, 10 Aug 2010 12:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.984 X-Spam-Level: X-Spam-Status: No, score=-9.984 tagged_above=-999 required=5 tests=[AWL=0.615, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 VQrc5YV4gJde for ; Tue, 10 Aug 2010 12:12:30 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by core3.amsl.com (Postfix) with ESMTP id 9A4BF3A695E for ; Tue, 10 Aug 2010 12:12:30 -0700 (PDT) Received: from 30-7-253.wireless.csail.mit.edu ([128.30.7.253]) by jay.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1OiuG0-0003cr-8S; Tue, 10 Aug 2010 15:13:04 -0400 From: Philippe Le Hegaret To: Mark Nottingham In-Reply-To: <9CDE7636-3E12-48AA-A351-FDD432112978@mnot.net> References: <9CDE7636-3E12-48AA-A351-FDD432112978@mnot.net> Content-Type: text/plain; charset="UTF-8" Organization: World Wide Web Consortium Date: Tue, 10 Aug 2010 15:13:03 -0400 Message-ID: <1281467583.701.298.camel@chacal> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 10 Aug 2010 12:36:25 -0700 Cc: Ian Hickson , Thomas Roessler , link-relations@ietf.org Subject: Re: [link-relations] NEW APP DATA X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 19:12:32 -0000 On Tue, 10 Aug 2010, Ian Hickson wrote: > Also, the WHATWG URLs are more stable than the W3C ones at this > point (the W3C keeps taking things out, splitting the specs into > other specs, etc), and I didn't want to have to keep updating the > registration. Correct, the consensus process of the W3C gives a chance to organizations and individuals that are part of the Web community to weight in on the content of the HTML specification. In addition, I would note that it seems that this registration request is premature and unstable, given the ongoing discussion within the HTML Working Group, as pointed out by Julian Reschtke. Regards, Philippe From derhoermi@gmx.net Tue Aug 10 13:43:44 2010 Return-Path: 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 393363A69B2 for ; Tue, 10 Aug 2010 13:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AWL=0.699, BAYES_00=-2.599] 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 V7gdRtjIwZpO for ; Tue, 10 Aug 2010 13:43:43 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id C22013A67B1 for ; Tue, 10 Aug 2010 13:43:42 -0700 (PDT) Received: (qmail invoked by alias); 10 Aug 2010 20:44:16 -0000 Received: from dslb-094-222-150-006.pools.arcor-ip.net (EHLO hive) [94.222.150.6] by mail.gmx.net (mp060) with SMTP; 10 Aug 2010 22:44:16 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX19soigRf0BsTqEcfBy6B5k9SwrfOLy3eZ3OrZWCZK ChKZW7kGmyZemF From: Bjoern Hoehrmann To: Ian Hickson Date: Tue, 10 Aug 2010 22:44:14 +0200 Message-ID: References: <9CDE7636-3E12-48AA-A351-FDD432112978@mnot.net> <1281459315.701.260.camel@chacal> In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: link-relations@ietf.org Subject: Re: [link-relations] NEW APP DATA X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 20:43:44 -0000 * Ian Hickson wrote: >On Tue, 10 Aug 2010, Julian Reschke wrote: >On Tue, 10 Aug 2010, Mark Nottingham wrote: >On Tue, 10 Aug 2010, Mark Nottingham wrote: >On Tue, 10 Aug 2010, Philippe Le Hegaret wrote: (As an aside, please be aware that folding many messages into one makes it harder to follow parts of a thread that one is interested in, harder to ignore parts one is not interested in, harder to restore the context of what is being discussed, easier for participants to reiterate points that have already been made without the appearance of flooding the list and in your case violates RFC 5322 which discourages forming References headers from multiple parents which your mail client does. Please count me among those who'd prefer you'd follow established conventions.) >I used the WHATWG URLs because the W3C doesn't publish a version of the >"complete.html" file that I used in the registration, and because the >WHATWG documents are generally more convenient to work with than the W3C >ones (e.g. it has bug filing tools, nicer styling, etc). It is my understanding that this document is meant to be a stress test, not an accessible specification. I believe you are well aware that this version of your proposals locks up in many people's browser and I do not see how a document, that is deliberately and unnecessarily made hard to access, would be a suitable reference for the registry, if there are al- ternatives available. It certainly locks up my browser of choice on any computer I've ever used that was meant to support regular web browsing. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From ian@hixie.ch Tue Aug 10 13:51:14 2010 Return-Path: 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 4459B3A6AD2 for ; Tue, 10 Aug 2010 13:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599] 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 BYMYaRFGcQmB for ; Tue, 10 Aug 2010 13:51:12 -0700 (PDT) Received: from homiemail-a49.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id 4E64B3A6AD8 for ; Tue, 10 Aug 2010 13:51:12 -0700 (PDT) Received: from homiemail-a49.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTP id B6FE15E0069; Tue, 10 Aug 2010 13:51:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=hixie.ch; h=date:from:to:cc :subject:in-reply-to:message-id:references:mime-version: content-type; q=dns; s=hixie.ch; b=ddpmVmS7p41jtEplJ0KW6aTmpW/+/ zqKzxlh3I6Vjb2vI/WavWb66nAlMsa/ibcew+0lKYVjUbu4Qg7GgQ/9COvHxA2xM 1aVpg+p8dlafQWVc3RlRds7mc7FCbeqxO/8gNRIAEbpMBADQuzwkSMhAMSLMaFC0 Od0BGLk9k2G8lM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hixie.ch; h=date:from:to :cc:subject:in-reply-to:message-id:references:mime-version: content-type; s=hixie.ch; bh=o1PVeo1VKf3ml9m4P+Un3jNaSZk=; b=fUO /kUfzv58p9jNwyTp8YAR57WGxecWx3O4GUEQOzqL5Amk5JPKM7YIY6Y18nEQlMMj 23mGNBHQaTL9/kEJRLDz5oO9VwSEh0E6j1LLiMz+pZFsJnRydoWlXUf4HLuGoEHK 2a9ThYFA3+RL2G9WqLPrZE581ueLZJTrgbLWqgpk= Received: from ps20323.dreamhostps.com (ps20323.dreamhost.com [69.163.222.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: internal@index.hixie.ch) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTPSA id A94D05E005F; Tue, 10 Aug 2010 13:51:47 -0700 (PDT) Date: Tue, 10 Aug 2010 20:51:47 +0000 (UTC) From: Ian Hickson To: Julian Reschke In-Reply-To: <4C61A834.40803@gmx.de> Message-ID: References: <9CDE7636-3E12-48AA-A351-FDD432112978@mnot.net> <1281459315.701.260.camel@chacal> <4C61A834.40803@gmx.de> Content-Language: en-GB-hixie Content-Style-Type: text/css MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: link-relations@ietf.org Subject: Re: [link-relations] app data wrt HTML usage, was: NEW APP DATA X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 20:51:14 -0000 On Tue, 10 Aug 2010, Julian Reschke wrote: > > > > Because it wouldn't make any sense on as defined. This is why > > conformance is an inherent part of the keywords. In fact, I am > > surprised other uses of these keywords don't have the same problem. > > For example, if we added "bookmark" (replacing the current > > registration which doesn't match real world usage of the keyword) to > > the registry, then a user agent would be unable to properly process it > > in an Atom environment or when used with a Link: header. > > So maybe the "new" definition is simply incorrect. Why did you change > it? To match real world usage. > > > - Unconvinced that and require different treatment. > > > > The simplest example of this is rel=stylesheet. > > That seems rather arbitrary, of course semantics for a/@rel=stylesheet *could* > be defined (scoped CSS comes to mind). Well that's as may be, but currently reality isn't so. I presume you would agree that the registry should match reality. > > > - Unconvinced that the default of "no" for is right. If > > > somebody defines a link relation, and it doesn't make sense > > > on, then it appears that something is very wrong with the > > > proposed semantics of the link relation. > > > > There are very few where this is the case, but I don't see why that > > would mean a relation where this is the case is wrong. > > If there are few, then this implies the default should not be "no". The "default" is merely a shorthand for not having to list every current relation and its new value; if you would rather I just list every relation I would be happy to do that. > That being said, I don't see anything in the definition of which > makes it different from what the HTTP Link header, for instance, > defines. Maybe you could elaborate? Elaborate on what? I didn't mention Link: headers here? I would not want to presuppose how Link: headers should work; I've already sent feedback on the Link: header work which has been rejected (e.g. the HTTP Link: header doesn't define how rel=stylesheet should work with the CSSOM, but that is apparently out of scope of the Link: header), so clearly my understanding of that issue is not complete. As such, I would certainly not want to presume to apply conformance requirements on usage of that header. > > The issues had in fact been decided in an appropriate venue; I was > > surprised to find any resistance in the registration. > > There was no conscious decision. As a matter of fact, there's a related > bug (), which > hasn't been processed yet. That's a different venue. The registration template links to a WHATWG specification, where this issue was considered and decided appropriately. > That's why we'd want the links to point at a published draft, not at > work-in-progress. The WHATWG spec is a published draft standard. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian@hixie.ch Tue Aug 10 14:10:36 2010 Return-Path: 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 F33F23A65A6 for ; Tue, 10 Aug 2010 14:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599] 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 6CzcrtFbABMW for ; Tue, 10 Aug 2010 14:10:34 -0700 (PDT) Received: from homiemail-a48.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id 239D03A6ADC for ; Tue, 10 Aug 2010 14:10:34 -0700 (PDT) Received: from homiemail-a48.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a48.g.dreamhost.com (Postfix) with ESMTP id 6443E4F806B for ; Tue, 10 Aug 2010 14:11:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=hixie.ch; h=date:from:to:subject :in-reply-to:message-id:references:mime-version:content-type; q= dns; s=hixie.ch; b=dXF5mrUHEGmQ9IIzO+HdxjCcfXROBibAdzt0GtvSU/4W2 nVXaakxfQMfo0dMBkagRPfq2lsvqwMTeSdtdhrYRzwSzQAcZqzR+wf18ftD4hRzK 8i08NkuIo4H7aYotocvIBU96RTVOdyGIQOrQeV62JS+/HH64jaa1FXUP/Sp/wA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hixie.ch; h=date:from:to :subject:in-reply-to:message-id:references:mime-version: content-type; s=hixie.ch; bh=EdVuu8dTS5ay1i8+lB0lY3uOiOA=; b=Yvm NWtudJhyMC9QW+L8ITWEBd1ZfLQT4i6NfEyKGe7kbeJpVsbjn4DN45oZSREuQwAw JT3pYZjINIfxR8X4ZKKfryNpF+UeuEoIcqBl11/7uCB1g5HyCOr44PjkWF6Agua4 +mSaikGa2fjVxOQmmMZOvyuoZzZAiJU+UCUjuz+I= Received: from ps20323.dreamhostps.com (ps20323.dreamhost.com [69.163.222.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: internal@index.hixie.ch) by homiemail-a48.g.dreamhost.com (Postfix) with ESMTPSA id 6147A4F806A for ; Tue, 10 Aug 2010 14:11:09 -0700 (PDT) Date: Tue, 10 Aug 2010 21:11:09 +0000 (UTC) From: Ian Hickson To: link-relations@ietf.org In-Reply-To: <4C61A497.8080106@gmx.de> Message-ID: References: <4C61A497.8080106@gmx.de> Content-Language: en-GB-hixie Content-Style-Type: text/css MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [link-relations] NEW RELATION REQUEST X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 21:10:36 -0000 On Tue, 10 Aug 2010, Julian Reschke wrote: > On 10.08.2010 20:17, Ian Hickson wrote: > > > > The template for this relation is in the specification as requested: > > > > http://www.whatwg.org/specs/web-apps/current-work/complete.html#rel-alternate-registration > > (beware - do not open with performance challenged UAs such as FF 3.x :-) > > This actually is an update for an existing registration. Looking at the text > from HTML4 and the current text I do not see a problem with the update. > > That being said, as the original registration refers to an W3C spec, I'd > expect the update to do so as well. Ok, updated. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian@hixie.ch Tue Aug 10 14:15:21 2010 Return-Path: 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 DAB4728C0E6 for ; Tue, 10 Aug 2010 14:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.431 X-Spam-Level: X-Spam-Status: No, score=-1.431 tagged_above=-999 required=5 tests=[AWL=-0.909, BAYES_00=-2.599, SUBJ_ALL_CAPS=2.077] 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 4NQnpWE+t6wp for ; Tue, 10 Aug 2010 14:15:20 -0700 (PDT) Received: from homiemail-a43.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id B6A9B28C0E2 for ; Tue, 10 Aug 2010 14:15:20 -0700 (PDT) Received: from homiemail-a43.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a43.g.dreamhost.com (Postfix) with ESMTP id F3E018C065 for ; Tue, 10 Aug 2010 14:15:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=hixie.ch; h=date:from:to:subject :message-id:mime-version:content-type; q=dns; s=hixie.ch; b=Hb7q 0z1JC4KZ6Lc/lOiwasvBs8k1jU9kTGzI4co34nXoOg+PtXJ0hDL2S+jGa1/Bc96C SkDsd/ITpsIpr9PR54gPAqeZmxHqd/0lTCQ00Y5y5aE7txGgLxHoOBZStjRQFO7T lgIyAaVzsD2A3lmSspbh9ymsFJOHtdc93R/CXoE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hixie.ch; h=date:from:to :subject:message-id:mime-version:content-type; s=hixie.ch; bh=oH kdc0HcFqf/+jFQBWpSsjmZtvA=; b=QTgR3fIw++egZHQQwxptROJ9FFMzAhEWzg kWQmZV1AzANtsKaABzQHcAysc0aql4ZKcNhmI0bk1XhkjcMdS56mOuHrkG1JbEI5 xUV/DfH9YUK58h772kdD9q2Q5D3Ye/cQ2rYmC4+BAnIeDcOJmYxUkK2dD/URash1 cvqMCFHxI= Received: from ps20323.dreamhostps.com (ps20323.dreamhost.com [69.163.222.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: internal@index.hixie.ch) by homiemail-a43.g.dreamhost.com (Postfix) with ESMTPSA id D88C68C05F for ; Tue, 10 Aug 2010 14:15:55 -0700 (PDT) Date: Tue, 10 Aug 2010 21:15:55 +0000 (UTC) From: Ian Hickson To: link-relations@ietf.org Message-ID: Content-Language: en-GB-hixie Content-Style-Type: text/css MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [link-relations] NEW RELATION REQUEST X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 21:15:22 -0000 The template for this relation is in the specification as requested: http://www.whatwg.org/specs/web-apps/current-work/complete.html#rel-archives-registration -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian@hixie.ch Tue Aug 10 14:15:21 2010 Return-Path: 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 DAB9F28C0E8 for ; Tue, 10 Aug 2010 14:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.419 X-Spam-Level: X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[AWL=-0.897, BAYES_00=-2.599, SUBJ_ALL_CAPS=2.077] 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 FyNUdmowX+85 for ; Tue, 10 Aug 2010 14:15:21 -0700 (PDT) Received: from homiemail-a42.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id 1F79628C0E3 for ; Tue, 10 Aug 2010 14:15:21 -0700 (PDT) Received: from homiemail-a42.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a42.g.dreamhost.com (Postfix) with ESMTP id B817D68C06E for ; Tue, 10 Aug 2010 14:15:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=hixie.ch; h=date:from:to:subject :message-id:mime-version:content-type; q=dns; s=hixie.ch; b=fVuP QKd6X+4NvUGUtxaQP6WBtYEWRhQAPNoSvkR0KnnQErlX9pwxhAwR8AwtEdzUGc1g qGQ0OpvO0HGQyMUydntrbMKqtzR7Dk6jJNPsJBPx8PGXMuoK74TLL5mHLbBxmI+N h/sMIWxZWKr9BGuEJansSjpofyrhYf6AAM5C07Y= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hixie.ch; h=date:from:to :subject:message-id:mime-version:content-type; s=hixie.ch; bh=qZ yB3l9JBIu9uBDqNUDsZMmDTt8=; b=WOSrbTpsHkFQbbwLPXzx0pHtlIlsv13Y1y nXzR5ONUifjjnPdSKKpCAjmfjxZTzaauKsXYRocJzRVZSJbR49q6arVjUaNh5bG6 lFNe41G/yGASS/BVvh4KFLomZycrQH2kcePilRCSOwmx4zf9xXMTgZq8vsFbeYpa wT0aRvl5A= Received: from ps20323.dreamhostps.com (ps20323.dreamhost.com [69.163.222.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: internal@index.hixie.ch) by homiemail-a42.g.dreamhost.com (Postfix) with ESMTPSA id AFCF168C065 for ; Tue, 10 Aug 2010 14:15:56 -0700 (PDT) Date: Tue, 10 Aug 2010 21:15:56 +0000 (UTC) From: Ian Hickson To: link-relations@ietf.org Message-ID: Content-Language: en-GB-hixie Content-Style-Type: text/css MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [link-relations] NEW RELATION REQUEST X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 21:15:22 -0000 o Relation Name: pingback o Description: Gives the address of the pingback server that handles pingbacks to the current document. o Reference: http://www.hixie.ch/specs/pingback/pingback o Notes: (none) o Application Data: (none) This registration template is not included in the specification since the specification was published in 2002. I hope that's ok. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From mnot@mnot.net Tue Aug 10 19:33:46 2010 Return-Path: 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 BA48F3A67ED for ; Tue, 10 Aug 2010 19:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.245 X-Spam-Level: X-Spam-Status: No, score=-105.245 tagged_above=-999 required=5 tests=[AWL=-2.646, 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 5DDnyjzvpXnz for ; Tue, 10 Aug 2010 19:33:45 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id 9914D3A6901 for ; Tue, 10 Aug 2010 19:33:42 -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 972ED22E259; Tue, 10 Aug 2010 22:34:11 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: Date: Wed, 11 Aug 2010 12:34:11 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <69D54950-1FE2-4714-9FED-569142BBF1A4@mnot.net> References: To: Ian Hickson 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 02:33:46 -0000 Overall looks good; two issues: 1) the template should be in the draft. 2) a document published on a personal web site doesn't meet the = requirement for the reference to be an RFC or Open Standard.=20 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. Cheers, =20 On 11/08/2010, at 7:15 AM, Ian Hickson wrote: >=20 > o Relation Name: pingback > o Description: Gives the address of the pingback server that handles=20= > pingbacks to the current document. > o Reference: http://www.hixie.ch/specs/pingback/pingback > o Notes: (none) > o Application Data: (none) >=20 > This registration template is not included in the specification since = the=20 > specification was published in 2002. I hope that's ok. >=20 > --=20 > Ian Hickson U+1047E )\._.,--....,'``. = fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ = ,. > Things that are impossible just take longer. = `._.-(,_..'--(,_..'`-.;.' > _______________________________________________ > link-relations mailing list > link-relations@ietf.org > https://www.ietf.org/mailman/listinfo/link-relations -- Mark Nottingham http://www.mnot.net/ From ian@hixie.ch Tue Aug 10 20:21:31 2010 Return-Path: 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 0F30A3A6814 for ; Tue, 10 Aug 2010 20:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599] 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 ZLDu12+jUdXE for ; Tue, 10 Aug 2010 20:21:29 -0700 (PDT) Received: from homiemail-a52.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id DFAFD3A6767 for ; Tue, 10 Aug 2010 20:21:29 -0700 (PDT) Received: from homiemail-a52.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a52.g.dreamhost.com (Postfix) with ESMTP id D98796B80C4; Tue, 10 Aug 2010 20:22:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=hixie.ch; h=date:from:to:cc :subject:in-reply-to:message-id:references:mime-version: content-type; q=dns; s=hixie.ch; b=3/jra4lgU90l03Sog+4MacmIJXP9Z F+Rtoz52wkJrvvMW05yYit4tkkyz6Mh3y+QglGq5pp+WbgwiaIBt9CiDK1EPtafF iC0pVeWGROePxJlzqjPRxyEt6a+cTtmiMEEJH+DRmeRR/RG0LvcttqjyaDVF3unm LmLPywuW99bgqI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hixie.ch; h=date:from:to :cc:subject:in-reply-to:message-id:references:mime-version: content-type; s=hixie.ch; bh=XMK4sqek/OJ6tP6I/XQ813Pk9Eo=; b=u8L IcGljPC0ZeCfhDsFr++DeGxWmTYT+G92MkHEpNOEt2n2CmS9bDeN3mS+MsY15j1H 67Elc00XKsPwEWkA1mr4TjwycTcXog0Pydy1rHjVl1pv8iEeUFGL6jqwOEVpOR9J dYJ6tiFlHjmr9gWbJVIDm/nIk6uebEOf2zMytbyA= Received: from ps20323.dreamhostps.com (ps20323.dreamhost.com [69.163.222.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: internal@index.hixie.ch) by homiemail-a52.g.dreamhost.com (Postfix) with ESMTPSA id D36016B80C2; Tue, 10 Aug 2010 20:22:04 -0700 (PDT) Date: Wed, 11 Aug 2010 03:22:04 +0000 (UTC) From: Ian Hickson To: Mark Nottingham In-Reply-To: <69D54950-1FE2-4714-9FED-569142BBF1A4@mnot.net> Message-ID: References: <69D54950-1FE2-4714-9FED-569142BBF1A4@mnot.net> Content-Language: en-GB-hixie Content-Style-Type: text/css MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 03:21:31 -0000 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? > 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? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From mnot@mnot.net Tue Aug 10 20:34:39 2010 Return-Path: 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 ; 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 ; 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 ; 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 In-Reply-To: Date: Wed, 11 Aug 2010 13:35:25 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <69D54950-1FE2-4714-9FED-569142BBF1A4@mnot.net> To: Ian Hickson 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: >>=20 >> Overall looks good; two issues: >>=20 >> 1) the template should be in the draft. >=20 > The draft is frozen. Is there no way to register a link relation for = old=20 > drafts? The HTML4 relations were registered without modifying HTML4, = no? Yes - they were registered in an RFC.=20 > 2) a document published on a personal web site doesn't meet the=20 >> requirement for the reference to be an RFC or Open Standard. >>=20 >> RE #2: there are a couple of things you could do to address this, but=20= >> probably the easiest would be to submit it to the RFC Editor for=20 >> publication as an independent submission Informational RFC. If you'd=20= >> like details on how to do this, just ask. >=20 > I'm not especially interested in publishing this document through the = IETF=20 > process (it would appear to be entirely busywork with no upside); does=20= > 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/ From ian@hixie.ch Tue Aug 10 21:49:35 2010 Return-Path: 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 AE6ED3A68D7 for ; Tue, 10 Aug 2010 21:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599] 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 zltQzar3zftf for ; Tue, 10 Aug 2010 21:49:33 -0700 (PDT) Received: from homiemail-a42.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id EAF693A68B0 for ; Tue, 10 Aug 2010 21:49:32 -0700 (PDT) Received: from homiemail-a42.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a42.g.dreamhost.com (Postfix) with ESMTP id D219668C065; Tue, 10 Aug 2010 21:50:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=hixie.ch; h=date:from:to:cc :subject:in-reply-to:message-id:references:mime-version: content-type; q=dns; s=hixie.ch; b=fBKLQB6c00/coaZcK78aj7bR7BKCu EygQ4UroFTrp5XWVKm1XXqfIbe84J51SD9L5aCMv/ivbOyzQqgNBfqp3yOraUdGR x4WWkkkq9Q3yH3r59wLZCtqAB3L3cmMFnoHGT2QDf9FO8NvT/3tH94RNtMBmQrBZ Z5Qr0f8r630tos= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hixie.ch; h=date:from:to :cc:subject:in-reply-to:message-id:references:mime-version: content-type; s=hixie.ch; bh=nqrjBmHeHrOHuQLLGiJzBTa/J2k=; b=tOH 77CEj8MdOkjeA405MBuDYxuEdDbamZ1DO9NhP7gyZgnrTFIOn2/DqrLqQL1nQabJ ozg8c539IDMLlaDiiDwOpKRx5aZYvSrCoKe8XcJK3RH0WmKGVl1EDnFAceF0PY72 lktbyVsP+wuC9+6E5XmbX64TNjilYpEwuLomH2zM= Received: from ps20323.dreamhostps.com (ps20323.dreamhost.com [69.163.222.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: internal@index.hixie.ch) by homiemail-a42.g.dreamhost.com (Postfix) with ESMTPSA id C42E368C05F; Tue, 10 Aug 2010 21:50:07 -0700 (PDT) Date: Wed, 11 Aug 2010 04:50:07 +0000 (UTC) From: Ian Hickson To: Mark Nottingham In-Reply-To: Message-ID: References: <69D54950-1FE2-4714-9FED-569142BBF1A4@mnot.net> Content-Language: en-GB-hixie Content-Style-Type: text/css MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 04:49:35 -0000 On Wed, 11 Aug 2010, Mark Nottingham wrote: > > > > 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. I see. > > 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. But there's no way to meet it that doesn't involve lots of busy work? > 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 Draft formatting is plenty of work already. All I'm trying to do here is make people who are interested in knowing what "pingback" means be able to find out, and make people who might be tempted to use that name aware of the existence of the keyword's existing use. Having to republish an eight year old spec seems like a lot of overhead. > 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. True, but presumably that's actually a good thing -- it means that if reality changes, and the spec is updated accordingly, the registration will still track it. It would seem that preventing changes is a bug, not a feature. (The spec is only currently frozen because Stuart and I don't think it needs changing at the moment and don't want to ramp up the process of changing it.) > 2) When you die and your Web site disappears, an RFC will have a better > chance of persisting in an unambiguous state. I don't think there's any risk of the pingback spec's state becoming ambiguous. If hixie.ch goes down, and people still care about the spec, someone can put up a copy elsewhere and update the registration. That doesn't seem like a problem of any practical importance. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From julian.reschke@gmx.de Wed Aug 11 01:47:20 2010 Return-Path: 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 3F8E13A67F6 for ; Wed, 11 Aug 2010 01:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.246 X-Spam-Level: X-Spam-Status: No, score=-103.246 tagged_above=-999 required=5 tests=[AWL=-0.647, 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 QypSxClP82n8 for ; Wed, 11 Aug 2010 01:47:19 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 9A5F03A6897 for ; Wed, 11 Aug 2010 01:47:17 -0700 (PDT) Received: (qmail invoked by alias); 11 Aug 2010 08:47:52 -0000 Received: from p508FE21D.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.226.29] by mail.gmx.net (mp053) with SMTP; 11 Aug 2010 10:47:52 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+njmoJ98inmn0O805WyIqOvT/yiez151FEY5SzMY C89JyTHVP5s59e Message-ID: <4C6263B2.9090008@gmx.de> Date: Wed, 11 Aug 2010 10:47:46 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Ian Hickson References: <4C61A497.8080106@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: link-relations@ietf.org Subject: Re: [link-relations] NEW RELATION REQUEST X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 08:47:20 -0000 On 10.08.2010 23:11, Ian Hickson wrote: > On Tue, 10 Aug 2010, Julian Reschke wrote: >> On 10.08.2010 20:17, Ian Hickson wrote: >>> >>> The template for this relation is in the specification as requested: >>> >>> http://www.whatwg.org/specs/web-apps/current-work/complete.html#rel-alternate-registration >> >> (beware - do not open with performance challenged UAs such as FF 3.x :-) >> >> This actually is an update for an existing registration. Looking at the text >> from HTML4 and the current text I do not see a problem with the update. >> >> That being said, as the original registration refers to an W3C spec, I'd >> expect the update to do so as well. > > Ok, updated. It's now: > This is the registration template for this value in the Link Relations registry: [IANALINKTYPE] > Relation Name: > alternate > Description: > Gives alternate representations of the current document, provides a link to a syndication feed, or modifies the meaning of other link relations, depending on context. > Reference: > http://dev.w3.org/html5/spec/Overview.html#rel-alternate > Notes: > (none) > Application Data: > (none) (side note: just because it should be in the spec doesn't mean it doesn't *also* make sense to post it here). That being said, I'm fine with this registration if it actually refers to the W3C Working Draft (that is, ). Best regards, Julian From julian.reschke@gmx.de Wed Aug 11 02:04:21 2010 Return-Path: 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 B67AE3A67D7 for ; Wed, 11 Aug 2010 02:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.23 X-Spam-Level: X-Spam-Status: No, score=-103.23 tagged_above=-999 required=5 tests=[AWL=-0.631, 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 BvJv-afOGw4K for ; Wed, 11 Aug 2010 02:04:20 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id 44CFD3A67CF for ; Wed, 11 Aug 2010 02:04:19 -0700 (PDT) Received: (qmail invoked by alias); 11 Aug 2010 09:04:54 -0000 Received: from p508FE21D.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.226.29] by mail.gmx.net (mp018) with SMTP; 11 Aug 2010 11:04:54 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+fID9kjSOfkHXKsC4H4DZoI9QDF7PCAWp39XrVJz ck79W7kHtO+DmK Message-ID: <4C6267AF.9060609@gmx.de> Date: Wed, 11 Aug 2010 11:04:47 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Ian Hickson References: <9CDE7636-3E12-48AA-A351-FDD432112978@mnot.net> <1281459315.701.260.camel@chacal> <4C61A834.40803@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: link-relations@ietf.org Subject: Re: [link-relations] app data wrt HTML usage, was: NEW APP DATA X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 09:04:21 -0000 On 10.08.2010 22:51, Ian Hickson wrote: >> So maybe the "new" definition is simply incorrect. Why did you change >> it? > > To match real world usage. So by doing this you broke a use case which may not be widely in use, but is legitimate. >>>> - Unconvinced that and require different treatment. >>> >>> The simplest example of this is rel=stylesheet. >> >> That seems rather arbitrary, of course semantics for a/@rel=stylesheet *could* >> be defined (scoped CSS comes to mind). > > Well that's as may be, but currently reality isn't so. I presume you would > agree that the registry should match reality. The purpose of the registry is to tell people what the semantics of a link relation are. It really doesn't matter whether that's already implemented or not. a/@rel=stylesheet indeed is not implemented (nor precisely defined), thus I have no problem with HTML validators pointing out that this is likely an authoring mistake. I just don't see why the type registry needs to contain this information. If we augment it with flags for each and every context links are used in, it will become hard to maintain. >>>> - Unconvinced that the default of "no" for is right. If >>>> somebody defines a link relation, and it doesn't make sense >>>> on, then it appears that something is very wrong with the >>>> proposed semantics of the link relation. >>> >>> There are very few where this is the case, but I don't see why that >>> would mean a relation where this is the case is wrong. >> >> If there are few, then this implies the default should not be "no". > > The "default" is merely a shorthand for not having to list every current > relation and its new value; if you would rather I just list every relation > I would be happy to do that. Incorrect; it's also the default for new values. >> That being said, I don't see anything in the definition of which >> makes it different from what the HTTP Link header, for instance, >> defines. Maybe you could elaborate? > > Elaborate on what? I didn't mention Link: headers here? I would not want > to presuppose how Link: headers should work; I've already sent feedback on > the Link: header work which has been rejected (e.g. the HTTP Link: header > doesn't define how rel=stylesheet should work with the CSSOM, but that is > apparently out of scope of the Link: header), so clearly my understanding > of that issue is not complete. As such, I would certainly not want to > presume to apply conformance requirements on usage of that header. OK. So I'll just state: if a link relation doesn't have the same meaning in and in Link: (the header field), there's a problem with the link relation, and we shouldn't register it. >>> The issues had in fact been decided in an appropriate venue; I was >>> surprised to find any resistance in the registration. >> >> There was no conscious decision. As a matter of fact, there's a related >> bug (), which >> hasn't been processed yet. > > That's a different venue. The registration template links to a WHATWG > specification, where this issue was considered and decided appropriately. So ignoring bug reports in W3C Bugzilla (which you yourself use as issue tracker for the WHATWG spec) means "was considered and decided appropriately"? >> That's why we'd want the links to point at a published draft, not at >> work-in-progress. > > The WHATWG spec is a published draft standard. Obviously we disagree on this. Best regards, Julian From ian@hixie.ch Wed Aug 11 02:23:49 2010 Return-Path: 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 197D43A6A55 for ; Wed, 11 Aug 2010 02:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599] 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 FY61+12qGJgw for ; Wed, 11 Aug 2010 02:23:48 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id EC1053A6A4C for ; Wed, 11 Aug 2010 02:23:47 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id 56A822C006B; Wed, 11 Aug 2010 02:24:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=hixie.ch; h=date:from:to:cc :subject:in-reply-to:message-id:references:mime-version: content-type; q=dns; s=hixie.ch; b=u7EsRZV2MxTBuveWzu9SJamJoCHQc dKdvmOEVJRofVxOFTQf5nZOccNBbA1/4apNtgK9aifq//LOFNWZzXp90fJmhpbR8 0TR9DrGaIaEKyvN80+4E+5ay0xqDpGxCoFMb7YKcnD45fZDBJ1x3isVuEhmsfAol fJP+cJgxiCm6b4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hixie.ch; h=date:from:to :cc:subject:in-reply-to:message-id:references:mime-version: content-type; s=hixie.ch; bh=H7qsy4EOrxj4iNEzbRapEIKOScA=; b=vbC nbbTCXh0l3ntvGUixOXvHGtzqYjMWH2aRgCflPrJq2E+AM6CL18Bq6GoNodxNtMD Wa08pa2hkGhDl4hHm0BhvWGsX1X8yU5/KpXjWAuFmI0LZSH1ERFi9pFp2FwAeC44 54OkbunXlmyGQ3/R9KyLUJMpaRtKUNUFgSnl470A= Received: from ps20323.dreamhostps.com (ps20323.dreamhost.com [69.163.222.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: internal@index.hixie.ch) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTPSA id 48ED52C006A; Wed, 11 Aug 2010 02:24:22 -0700 (PDT) Date: Wed, 11 Aug 2010 09:24:22 +0000 (UTC) From: Ian Hickson To: Julian Reschke In-Reply-To: <4C6267AF.9060609@gmx.de> Message-ID: References: <9CDE7636-3E12-48AA-A351-FDD432112978@mnot.net> <1281459315.701.260.camel@chacal> <4C61A834.40803@gmx.de> <4C6267AF.9060609@gmx.de> Content-Language: en-GB-hixie Content-Style-Type: text/css MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: link-relations@ietf.org Subject: Re: [link-relations] app data wrt HTML usage, was: NEW APP DATA X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 09:23:49 -0000 This thread is going off the topic of the field registrations, so I've only replied to the relevant parts here. On Wed, 11 Aug 2010, Julian Reschke wrote: > > a/@rel=stylesheet indeed is not implemented (nor precisely defined), > thus I have no problem with HTML validators pointing out that this is > likely an authoring mistake. I just don't see why the type registry > needs to contain this information. Understood. > > > > > - Unconvinced that the default of "no" for is right. If > > > > > somebody defines a link relation, and it doesn't make sense > > > > > on, then it appears that something is very wrong with the > > > > > proposed semantics of the link relation. > > > > > > > > There are very few where this is the case, but I don't see why > > > > that would mean a relation where this is the case is wrong. > > > > > > If there are few, then this implies the default should not be "no". > > > > The "default" is merely a shorthand for not having to list every > > current relation and its new value; if you would rather I just list > > every relation I would be happy to do that. > > Incorrect; it's also the default for new values. Surely for new values we would want the people submitting registrations to consider how their relations will work with existing applications and thus they will explicitly say what the values should be? I would not at all feel comfortable defaulting all future values to either "hyperlink", "external resource link", or "annotation link". Which one applies should be carefully considered in each case. If no consideration is made, the only safe answer IMHO is "not allowed". This argues strongly, again IMHO, that we absolutely must have the latter as one of the possible options, if we are to have this field at all. At this point my assumption is that the field registration is being rejected and we will have to deal with it outside the registry. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian@hixie.ch Wed Aug 11 02:26:10 2010 Return-Path: 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 789B23A6A42 for ; Wed, 11 Aug 2010 02:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599] 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 UyB5TVkF6or2 for ; Wed, 11 Aug 2010 02:26:09 -0700 (PDT) Received: from homiemail-a48.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id 94A183A6982 for ; Wed, 11 Aug 2010 02:26:09 -0700 (PDT) Received: from homiemail-a48.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a48.g.dreamhost.com (Postfix) with ESMTP id 043D34F806A; Wed, 11 Aug 2010 02:26:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=hixie.ch; h=date:from:to:cc :subject:in-reply-to:message-id:references:mime-version: content-type; q=dns; s=hixie.ch; b=MF3a3vwhpMKE8w+iSmXzkmwM4Vctr dGxXNVNDRozgs51XYpv/HBzP4TLrcBNxdxCMyI4rmcBBAXMo+QcNrVk+KNzwlTiG B+nDxJvwJN7U+obOAq3aK+SQ3XdIEJaXvnuMmOJFZdapfz41Iiaunfb7u0N8eUNa luiqw8L0IZYmyM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hixie.ch; h=date:from:to :cc:subject:in-reply-to:message-id:references:mime-version: content-type; s=hixie.ch; bh=ePuiv5nt7OIwm+OKHuHtrewrxBI=; b=zTr 42QeQ/YbyWeSlRWsfcOhqiiHb3QvSUZCvWgwCgTs/v64I0EzhhAw3vlUbPzs13sf OkAfgTnudeuBm4n3lbgpLZeM1g23k6lU7Vtlylvm8e19gfUyXtpbAiI9pbU8Qgrs 9eyl+gwaDfHQ09LTvnCHAdwstAnXWdDEsMTA0ETw= Received: from ps20323.dreamhostps.com (ps20323.dreamhost.com [69.163.222.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: internal@index.hixie.ch) by homiemail-a48.g.dreamhost.com (Postfix) with ESMTPSA id F22094F8065; Wed, 11 Aug 2010 02:26:44 -0700 (PDT) Date: Wed, 11 Aug 2010 09:26:44 +0000 (UTC) From: Ian Hickson To: Julian Reschke In-Reply-To: <4C6263B2.9090008@gmx.de> Message-ID: References: <4C61A497.8080106@gmx.de> <4C6263B2.9090008@gmx.de> Content-Language: en-GB-hixie Content-Style-Type: text/css MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: link-relations@ietf.org Subject: Re: [link-relations] NEW RELATION REQUEST X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 09:26:10 -0000 On Wed, 11 Aug 2010, Julian Reschke wrote: > On 10.08.2010 23:11, Ian Hickson wrote: > > On Tue, 10 Aug 2010, Julian Reschke wrote: > > > On 10.08.2010 20:17, Ian Hickson wrote: > > > > > > > > The template for this relation is in the specification as requested: > > > > > > > > http://www.whatwg.org/specs/web-apps/current-work/complete.html#rel-alternate-registration > > > > > > (beware - do not open with performance challenged UAs such as FF 3.x :-) > > > > > > This actually is an update for an existing registration. Looking at the > > > text > > > from HTML4 and the current text I do not see a problem with the update. > > > > > > That being said, as the original registration refers to an W3C spec, I'd > > > expect the update to do so as well. > > > > Ok, updated. > > It's now: > > > This is the registration template for this value in the Link Relations > > registry: [IANALINKTYPE] > > Relation Name: > > alternate > > Description: > > Gives alternate representations of the current document, provides a link to > > a syndication feed, or modifies the meaning of other link relations, > > depending on context. > > Reference: > > http://dev.w3.org/html5/spec/Overview.html#rel-alternate > > Notes: > > (none) > > Application Data: > > (none) > > (side note: just because it should be in the spec doesn't mean it doesn't > *also* make sense to post it here). > > That being said, I'm fine with this registration if it actually refers to the > W3C Working Draft (that is, ). So to be clear, you are rejecting this registration unless it references the out-of-date snapshot document on the W3C site rather than either the WHATWG document or the current W3C document? (So in particular, you are rejecting this registration at least until the next snapshot publication?) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From julian.reschke@gmx.de Wed Aug 11 03:06:22 2010 Return-Path: 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 1F8DC3A6890 for ; Wed, 11 Aug 2010 03:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.032 X-Spam-Level: X-Spam-Status: No, score=-104.032 tagged_above=-999 required=5 tests=[AWL=-1.433, 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 itP4ZjlYiqEN for ; Wed, 11 Aug 2010 03:06:21 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id C89F73A6855 for ; Wed, 11 Aug 2010 03:06:20 -0700 (PDT) Received: (qmail invoked by alias); 11 Aug 2010 10:06:55 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.147]) [217.91.35.233] by mail.gmx.net (mp071) with SMTP; 11 Aug 2010 12:06:55 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX187+NQaagY7NN+wYySFkezqUNa7j2T6MaGfbZAREk yKs2dAuJdCC1cr Message-ID: <4C627639.6040307@gmx.de> Date: Wed, 11 Aug 2010 12:06:49 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Ian Hickson References: <4C61A497.8080106@gmx.de> <4C6263B2.9090008@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: link-relations@ietf.org Subject: Re: [link-relations] NEW RELATION REQUEST X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 10:06:22 -0000 On 11.08.2010 11:26, Ian Hickson wrote: > ... >> It's now: >> >>> This is the registration template for this value in the Link Relations >>> registry: [IANALINKTYPE] >>> Relation Name: >>> alternate >>> Description: >>> Gives alternate representations of the current document, provides a link to >>> a syndication feed, or modifies the meaning of other link relations, >>> depending on context. >>> Reference: >>> http://dev.w3.org/html5/spec/Overview.html#rel-alternate >>> Notes: >>> (none) >>> Application Data: >>> (none) >> >> (side note: just because it should be in the spec doesn't mean it doesn't >> *also* make sense to post it here). >> >> That being said, I'm fine with this registration if it actually refers to the >> W3C Working Draft (that is,). > > So to be clear, you are rejecting this registration unless it references > the out-of-date snapshot document on the W3C site rather than either the > WHATWG document or the current W3C document? (So in particular, you are > rejecting this registration at least until the next snapshot publication?) >... I haven't rejected anything. I'm saying that the registration should point to a stable document in W3C space, and I don't think the "current editor's copy" qualifies as that. What's the problem with waiting with the actual registration until the new WD is out? Best regards, Julian From julian.reschke@gmx.de Wed Aug 11 03:10:19 2010 Return-Path: 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 BABF33A6857 for ; Wed, 11 Aug 2010 03:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.996 X-Spam-Level: X-Spam-Status: No, score=-103.996 tagged_above=-999 required=5 tests=[AWL=-1.397, 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 7O3BKXyAyJpv for ; Wed, 11 Aug 2010 03:10:15 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 480D33A6A6F for ; Wed, 11 Aug 2010 03:10:13 -0700 (PDT) Received: (qmail invoked by alias); 11 Aug 2010 10:10:48 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.147]) [217.91.35.233] by mail.gmx.net (mp023) with SMTP; 11 Aug 2010 12:10:48 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+r9rxyJ8erJu2TGkn2ShC5yiBfHojO13h8y3ErvQ fOzxdYgCmXc+vu Message-ID: <4C62771B.4040603@gmx.de> Date: Wed, 11 Aug 2010 12:10:35 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Ian Hickson References: <9CDE7636-3E12-48AA-A351-FDD432112978@mnot.net> <1281459315.701.260.camel@chacal> <4C61A834.40803@gmx.de> <4C6267AF.9060609@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: link-relations@ietf.org Subject: Re: [link-relations] app data wrt HTML usage, was: NEW APP DATA X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 10:10:19 -0000 On 11.08.2010 11:24, Ian Hickson wrote: > > This thread is going off the topic of the field registrations, so I've > only replied to the relevant parts here. Indeed. > .. >> Incorrect; it's also the default for new values. > > Surely for new values we would want the people submitting registrations to > consider how their relations will work with existing applications and thus > they will explicitly say what the values should be? Yes, but the thing we do not agree on is the level of detail required. The application data registry was created to deal with the use case of distinguishing between links and external resources, for instance, so a client knows what to archive or to download for offline access. I think this is a good use case, and it covers *most* of what you're looking for. > I would not at all feel comfortable defaulting all future values to either > "hyperlink", "external resource link", or "annotation link". Which one > applies should be carefully considered in each case. If no consideration > is made, the only safe answer IMHO is "not allowed". This argues strongly, > again IMHO, that we absolutely must have the latter as one of the possible > options, if we are to have this field at all. See above: by defining the flag in general terms instead of HTML-specific terms, the question simply goes away. > At this point my assumption is that the field registration is being > rejected and we will have to deal with it outside the registry. Again, please consider simplifying the application data, as originally discussed. Best regards, Julian From ian@hixie.ch Wed Aug 11 10:33:42 2010 Return-Path: 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 382E73A6AEA for ; Wed, 11 Aug 2010 10:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.457 X-Spam-Level: X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599] 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 vuFCQvfzyoyj for ; Wed, 11 Aug 2010 10:33:40 -0700 (PDT) Received: from homiemail-a44.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id 8C5B83A6AE8 for ; Wed, 11 Aug 2010 10:33:40 -0700 (PDT) Received: from homiemail-a44.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a44.g.dreamhost.com (Postfix) with ESMTP id A2F69118064; Wed, 11 Aug 2010 10:34:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=hixie.ch; h=date:from:to:cc :subject:in-reply-to:message-id:references:mime-version: content-type; q=dns; s=hixie.ch; b=SNtalbyjIt4UXlFiaeK67BORNeuQa FsyQ347Q61CnLZh9b+JPD8+WrZ98bjjeO5p7sjiSyt7gi3sm3nmBPrXsrzWtHHP+ gdbO1LXc9twJJwKP68P2HgnarWNwv5RoSHlKdhs4DAFmSvrhbldOC1wsCclZGSpM 2xDuOCfHwTNL64= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hixie.ch; h=date:from:to :cc:subject:in-reply-to:message-id:references:mime-version: content-type; s=hixie.ch; bh=9AJ65UDVB0h6fszeFQzZ2xCbyUQ=; b=HFy 3dhdHcZmkS+inNL3uPzfcufx5vApzSaVS2Msg5ZBrM5AzGZJIIay7xe54tst02kt JUIhTKpbrBexMtEzqNjwf/LudfGS1xQCL4/tiU8bmDrBiSwiCTp5clgv+PhNACaI FNcigvoA4n2uAX3Hg5WXAifX2hAEWTs6Hu3CsAyM= Received: from ps20323.dreamhostps.com (ps20323.dreamhost.com [69.163.222.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: internal@index.hixie.ch) by homiemail-a44.g.dreamhost.com (Postfix) with ESMTPSA id 9E7D2118060; Wed, 11 Aug 2010 10:34:16 -0700 (PDT) Date: Wed, 11 Aug 2010 17:34:16 +0000 (UTC) From: Ian Hickson To: Julian Reschke In-Reply-To: <4C627639.6040307@gmx.de> Message-ID: References: <4C61A497.8080106@gmx.de> <4C6263B2.9090008@gmx.de> <4C627639.6040307@gmx.de> Content-Language: en-GB-hixie Content-Style-Type: text/css MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: link-relations@ietf.org Subject: Re: [link-relations] NEW RELATION REQUEST X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 17:33:42 -0000 On Wed, 11 Aug 2010, Julian Reschke wrote: > > > > > > That being said, I'm fine with this registration if it actually > > > refers to the W3C Working Draft (that > > > is,). > > > > So to be clear, you are rejecting this registration unless it > > references the out-of-date snapshot document on the W3C site rather > > than either the WHATWG document or the current W3C document? (So in > > particular, you are rejecting this registration at least until the > > next snapshot publication?) ... > > I haven't rejected anything. I'm saying that the registration should > point to a stable document in W3C space, and I don't think the "current > editor's copy" qualifies as that. > > What's the problem with waiting with the actual registration until the > new WD is out? The TR/ page drafts are out-of-date obsolete drafts. We shouldn't be using them as a reference, as they are almost by definition known to be incorrect. (I don't believe we have ever published a TR/ draft of this specification that was up-to-date when it was published.) I would definitely not consider it acceptable to have the registration point to a document that is known to be wrong. It's not clear what benefit it would bring, either. That draft is no more stable (it changes frequently), it's no more representative of consensus (we have always had more outstanding known issues when publishing than the contemporary editor's draft), and it is technically inferior (again, it has always been published with more known issues). -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From xn--mlform-iua@xn--mlform-iua.no Wed Aug 11 21:43:29 2010 Return-Path: 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 B24D73A68E0 for ; Wed, 11 Aug 2010 21:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_20=-0.74] 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 x9o-Gg-tWhea for ; Wed, 11 Aug 2010 21:43:28 -0700 (PDT) Received: from smtp.domeneshop.no (smtp.domeneshop.no [194.63.248.54]) by core3.amsl.com (Postfix) with ESMTP id B0C0E3A6767 for ; Wed, 11 Aug 2010 21:43:28 -0700 (PDT) Received: from cm-84.208.110.159.getinternet.no ([84.208.110.159] helo=[10.0.1.3]) by smtp.domeneshop.no with esmtpa (Exim 4.71) (envelope-from ) id 1OjPe7-0002H0-Pd for link-relations@ietf.org; Thu, 12 Aug 2010 06:44:03 +0200 Date: Thu, 12 Aug 2010 06:44:03 +0200 From: Leif Halvard Silli To: link-relations@ietf.org Message-ID: <20100812064403354963.8375d0b7@xn--mlform-iua.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Organization: =?iso-8859-1?Q?M=E5lform.no?= X-Mailer: GyazMail version 1.5.9 Subject: [link-relations] rel="longdesc" X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 04:43:29 -0000 Hi! I consider registering "longdesc" as a link relation. What is the best way forward for something like that? Longdesc is the name of a link attribute of , and