From dret@berkeley.edu Tue Oct 9 13:20:23 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 000FA1F0422; Tue, 9 Oct 2012 13:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.11 X-Spam-Level: X-Spam-Status: No, score=-5.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fbBr-7PNcsU; Tue, 9 Oct 2012 13:20:22 -0700 (PDT) Received: from cm01fe.IST.Berkeley.EDU (cm01fe.IST.Berkeley.EDU [169.229.218.142]) by ietfa.amsl.com (Postfix) with ESMTP id 625911F041C; Tue, 9 Oct 2012 13:20:22 -0700 (PDT) Received: from rrcs-24-43-215-50.west.biz.rr.com ([24.43.215.50] helo=dretair.local) by cm01fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1TLgHo-0004qz-40; Tue, 09 Oct 2012 13:20:21 -0700 Message-ID: <507486FE.2050601@berkeley.edu> Date: Tue, 09 Oct 2012 10:20:14 -1000 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: link-relations@ietf.org Subject: request to register 'describes' link relation (http://tools.ietf.org/html/draft-wilde-describes-link-01) Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: hypermedia-web@googlegroups.com, LDP WG , REST-Discuss , "apps-discuss@ietf.org application-layer protocols" X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 20:20:23 -0000 dear link-relations experts, this is a request to register 'describes' in the IANA link relations registry established by RFC 5988. the latest draft of the registration document is available at http://tools.ietf.org/html/draft-wilde-describes-link-01, and the last version announced on a variety of mailing lists has not generated any feedback asking for changes. should the registration request be accepted, my understanding is that the draft registration document will be forwarded to IANA for registration by a designated expert. thanks a lot and kind regards, erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From barryleiba.mailing.lists@gmail.com Tue Oct 9 16:40:10 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBA1711E80ED; Tue, 9 Oct 2012 16:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.089 X-Spam-Level: X-Spam-Status: No, score=-103.089 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFnF2QtKwSCr; Tue, 9 Oct 2012 16:40:07 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 63E0411E80E8; Tue, 9 Oct 2012 16:40:06 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so3812835lam.31 for ; Tue, 09 Oct 2012 16:40:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=EF1XM0TRpEluUNn53Sh4nApCMLOPuLgNUxdAzClnRRo=; b=ZxlIJ9RhI5AFr60+0yzH/7JjyfoRVoWcIvFcHUb1F1GCsGYKbLtAbZGvsbljC3LWBe JoZEfxpGH/ssIfIw8gbDQUDJ6xQu87OPCiywlK6qWkklsc01oAIDHYxDndpIJGWRo1jW W7rzsk8E5ttXk8csi7AhAIiH9gLMRtuToN/uXt1bDQaJEQsuHK5KxIEwWs/cEhscSet5 l517hQDJVyIuXl0WZ6BO2E2cJQc1GgJcMWW9PyGhz46AkMykY9khnrAxTS7LoRIQAZDZ EtfuF1jZpHfzlZ5Nwrav4dMon2+IoGkjS2lQLYzW9Eqp6g/vPJ5654sveF3eVmcXWtmW jCSA== MIME-Version: 1.0 Received: by 10.112.103.7 with SMTP id fs7mr3469251lbb.25.1349826005265; Tue, 09 Oct 2012 16:40:05 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.150.194 with HTTP; Tue, 9 Oct 2012 16:40:05 -0700 (PDT) In-Reply-To: <507486FE.2050601@berkeley.edu> References: <507486FE.2050601@berkeley.edu> Date: Tue, 9 Oct 2012 19:40:05 -0400 X-Google-Sender-Auth: gkZKcscjYRmdeA7xIP0K29h7NRY Message-ID: Subject: Re: [apps-discuss] request to register 'describes' link relation (http://tools.ietf.org/html/draft-wilde-describes-link-01) From: Barry Leiba To: Erik Wilde Content-Type: text/plain; charset=ISO-8859-1 Cc: apps-discuss@ietf.org, link-relations@ietf.org X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 23:40:10 -0000 [I'm removing the non-IETF groups from the distribution list.] > this is a request to register 'describes' in the IANA link relations > registry established by RFC 5988. the latest draft of the registration > document is available at > http://tools.ietf.org/html/draft-wilde-describes-link-01, and the last > version announced on a variety of mailing lists has not generated any > feedback asking for changes. I'll let the folks on the link-relations list respond to the suitability of the specification for documenting a useful link relation. I have just a couple of process points: 1. In order for the registration to be done, this document will have to be published somewhere that will satisfy the Designated Expert as being a stable reference. That probably means that you'll want this to be an RFC, so you need to be sorting out how that will happen. Happily, I'm willing to sponsor this as an AD-sponsored individual submission, if the link-relations folks agree that we should register this. 2. I don't think this should be Standards Track, though (and it doesn't need to be in order to register the link relation and to be the reference documentation for it). I would prefer that you make it Informational, change the "SHOULD" to "should" in the Security Considerations, and remove Section 2 and the normative reference to RFC 2119. (This can wait until after the feedback from the link-relations mailing list.) Barry, Applications AD From dret@berkeley.edu Tue Oct 9 17:16:51 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5759C11E80EF for ; Tue, 9 Oct 2012 17:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZsHkZEPnGhq for ; Tue, 9 Oct 2012 17:16:50 -0700 (PDT) Received: from cm02fe.IST.Berkeley.EDU (cm02fe.IST.Berkeley.EDU [169.229.218.143]) by ietfa.amsl.com (Postfix) with ESMTP id 4817511E80EE for ; Tue, 9 Oct 2012 17:16:50 -0700 (PDT) Received: from rrcs-24-43-239-58.west.biz.rr.com ([24.43.239.58] helo=dretair.local) by cm02fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1TLjyi-0005bv-70; Tue, 09 Oct 2012 17:16:49 -0700 Message-ID: <5074BE6C.2040803@berkeley.edu> Date: Tue, 09 Oct 2012 14:16:44 -1000 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Barry Leiba Subject: Re: [apps-discuss] request to register 'describes' link relation (http://tools.ietf.org/html/draft-wilde-describes-link-01) References: <507486FE.2050601@berkeley.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: link-relations@ietf.org X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 00:16:51 -0000 hello barry. On 2012-10-09 13:40 , Barry Leiba wrote: > [I'm removing the non-IETF groups from the distribution list.] thanks. i have also removed apps-discuss for now. > I'll let the folks on the link-relations list respond to the > suitability of the specification for documenting a useful link > relation. I have just a couple of process points: thanks for the feedback. i guess i am still a bit confused about the process. my understanding was that the link-relations experts would provide feedback, and then it would be sponsored as an RFC. apparently, that's not how things are working. also, please be advised that another similar request was sent to the link-relations and apps-discuss experts very recently (http://www.ietf.org/mail-archive/web/apps-discuss/current/msg07356.html), and i guess your comments apply to this other request as well. > 1. In order for the registration to be done, this document will have > to be published somewhere that will satisfy the Designated Expert as > being a stable reference. That probably means that you'll want this > to be an RFC, so you need to be sorting out how that will happen. > Happily, I'm willing to sponsor this as an AD-sponsored individual > submission, if the link-relations folks agree that we should register > this. thanks. would you be willing to sponsor the other draft (http://tools.ietf.org/html/draft-wilde-profile-link-03) as well? > 2. I don't think this should be Standards Track, though (and it > doesn't need to be in order to register the link relation and to be > the reference documentation for it). I would prefer that you make it > Informational, change the "SHOULD" to "should" in the Security > Considerations, and remove Section 2 and the normative reference to > RFC 2119. (This can wait until after the feedback from the > link-relations mailing list.) i assume these changes would apply to the other draft as well. for now i will wait for the feedback from the link-relations experts, and if they seem to be in favor, i will prepare new versions for both drafts, changing the track, and making the other changes you have mentioned. thanks and cheers, dret. -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From barryleiba.mailing.lists@gmail.com Tue Oct 9 17:19:14 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 017EB11E80EE; Tue, 9 Oct 2012 17:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.08 X-Spam-Level: X-Spam-Status: No, score=-103.08 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDp0Q+zf6+pn; Tue, 9 Oct 2012 17:19:13 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id EA84121F857E; Tue, 9 Oct 2012 17:19:11 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so24980lbo.31 for ; Tue, 09 Oct 2012 17:19:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=9SG1P5qSIB32Xj1/RXV1ObFwK2a3ae2LQk7ZfcdpYyo=; b=hGCYfKBhNr3nBIwYVBFsiLuEfdawdmU/OT0QveIJiqaq5ciR06YXeKesTO+K6goMiB m4js8w4aO28oyW5rweoUz0ui2baxacDXyPV1cylSuxZRDfSqPlJ7suyzp1SN8asWKXBQ ML/nunJbP55FLkwkqQY1kW8QX39nP+71otrBoOfaUTQbMfawZRDL0t3pcK0nWwcl1f6P qtogG9KhpSxvSzrwdZf3hcnQ3oKH85uNEnYkL0DlQ1yZa1v2DmYeupYdgJAGXxLQ1srN S8DVgGngXUn7EJKCoohYrFZ+HBnDaqWnsZaosvyjb8eiBGkBQNqdyrksvrAKyH2mT1f1 We/A== MIME-Version: 1.0 Received: by 10.112.47.133 with SMTP id d5mr8916569lbn.47.1349828350898; Tue, 09 Oct 2012 17:19:10 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.150.194 with HTTP; Tue, 9 Oct 2012 17:19:10 -0700 (PDT) In-Reply-To: References: <507486FE.2050601@berkeley.edu> Date: Tue, 9 Oct 2012 20:19:10 -0400 X-Google-Sender-Auth: rxI7hS_XWcm72eNOuR-Ps15Xljw Message-ID: Subject: Re: [apps-discuss] request to register 'describes' link relation (http://tools.ietf.org/html/draft-wilde-describes-link-01) From: Barry Leiba To: James M Snell Content-Type: text/plain; charset=ISO-8859-1 Cc: apps-discuss@ietf.org, link-relations@ietf.org X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 00:19:14 -0000 > Sticking my hand up and hoping to get some similar treatment for: > > http://www.ietf.org/id/draft-snell-additional-link-relations-05.txt > > This one has been there for a while. I followed the same advice you just > gave dret and changed it to informational and cleaned up the normative > references. Pretty basic draft. Indeed. I suggest that you change the references in each template to include the section number -- not that the document is long enough to really matter, but I very much like the cleanliness of it. For example: o Relation Name: about o Description: Refers to a resource that is the subject of the link's context. o Reference: This specification, Section 2. Link-relations folk, consider this a formal request for review of the five relations in the above draft. After comments here, I'll send the document out for IETF last call. Barry From dret@berkeley.edu Tue Oct 9 17:19:49 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7560F1F0C5C; Tue, 9 Oct 2012 17:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.227 X-Spam-Level: X-Spam-Status: No, score=-6.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wSNZhin6iHMv; Tue, 9 Oct 2012 17:19:48 -0700 (PDT) Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) by ietfa.amsl.com (Postfix) with ESMTP id BC05B1F0C4C; Tue, 9 Oct 2012 17:19:48 -0700 (PDT) Received: from rrcs-24-43-239-58.west.biz.rr.com ([24.43.239.58] helo=dretair.local) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1TLk1a-00053B-Ca; Tue, 09 Oct 2012 17:19:48 -0700 Message-ID: <5074BF1F.7030608@berkeley.edu> Date: Tue, 09 Oct 2012 14:19:43 -1000 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Barry Leiba Subject: Re: [apps-discuss] request to register 'describes' link relation (http://tools.ietf.org/html/draft-wilde-describes-link-01) References: <507486FE.2050601@berkeley.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org application-layer protocols" , link-relations@ietf.org X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 00:19:49 -0000 hello barry. On 2012-10-09 13:40 , Barry Leiba wrote: > [I'm removing the non-IETF groups from the distribution list.] i tried sending this to barry only, but barryleiba@computer.org does not seem to be a valid email address, so i'll respond to the list and hope barry will get in trough the list somehow. > I'll let the folks on the link-relations list respond to the > suitability of the specification for documenting a useful link > relation. I have just a couple of process points: thanks for the feedback. i guess i am still a bit confused about the process. my understanding was that the link-relations experts would provide feedback, and then it would be sponsored as an RFC. apparently, that's not how things are working. also, please be advised that another similar request was sent to the link-relations and apps-discuss experts very recently (http://www.ietf.org/mail-archive/web/apps-discuss/current/msg07356.html), and i guess your comments apply to this other request as well. > 1. In order for the registration to be done, this document will have > to be published somewhere that will satisfy the Designated Expert as > being a stable reference. That probably means that you'll want this > to be an RFC, so you need to be sorting out how that will happen. > Happily, I'm willing to sponsor this as an AD-sponsored individual > submission, if the link-relations folks agree that we should register > this. thanks. would you be willing to sponsor the other draft (http://tools.ietf.org/html/draft-wilde-profile-link-03) as well? > 2. I don't think this should be Standards Track, though (and it > doesn't need to be in order to register the link relation and to be > the reference documentation for it). I would prefer that you make it > Informational, change the "SHOULD" to "should" in the Security > Considerations, and remove Section 2 and the normative reference to > RFC 2119. (This can wait until after the feedback from the > link-relations mailing list.) i assume these changes would apply to the other draft as well. for now i will wait for the feedback from the link-relations experts, and if they seem to be in favor, i will prepare new versions for both drafts, changing the track, and making the other changes you have mentioned. thanks and cheers, dret. -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From barryleiba.mailing.lists@gmail.com Tue Oct 9 17:35:27 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2471F0C71; Tue, 9 Oct 2012 17:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.079 X-Spam-Level: X-Spam-Status: No, score=-103.079 tagged_above=-999 required=5 tests=[AWL=-0.102, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOjb6x-0KhXk; Tue, 9 Oct 2012 17:35:26 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id A18211F0C4C; Tue, 9 Oct 2012 17:35:25 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so3837343lam.31 for ; Tue, 09 Oct 2012 17:35:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=/4xkzJtSjIOJwIJStM5THHQQ7LnCHCHtBiMutLiGVNQ=; b=Zl8Sjd4Exmn8La0yH1pmLOqzS32al7y3VuhBwIq8fYRgvvpIdze8I9Qn8fQAKk9uxo dv2/HO/RtyxXqwmtRG2IfQbJQ6iPiITy164wuNRD/5ciJRWRzYOdkGgrM/VALOeIXp68 /KHByXrkhjGQzyh9E6QdaDtd5S3pUWtFdG3rpZiLDaEuVDVA9/UVY/3xZX1eKZ6BMhps ZCaZa4q7yeqLxI9mtxC1NFSwq+5t/omLLBcw2OjuLFuNGdPf+azaKjxDayraRaJgRYbC +SHT0k4g2kBJHcn6dGcsB/D9aWomPESmA5CROWfzHoMhI8oqIcDeOLkyD4/cCa5xFMwh /stA== MIME-Version: 1.0 Received: by 10.152.108.197 with SMTP id hm5mr9303982lab.45.1349829324577; Tue, 09 Oct 2012 17:35:24 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.150.194 with HTTP; Tue, 9 Oct 2012 17:35:24 -0700 (PDT) In-Reply-To: <5074BF1F.7030608@berkeley.edu> References: <507486FE.2050601@berkeley.edu> <5074BF1F.7030608@berkeley.edu> Date: Tue, 9 Oct 2012 20:35:24 -0400 X-Google-Sender-Auth: me5Zbp9kSsXnqgcLvVVWHUIlm-4 Message-ID: Subject: Re: [apps-discuss] request to register 'describes' link relation (http://tools.ietf.org/html/draft-wilde-describes-link-01) From: Barry Leiba To: Erik Wilde Content-Type: text/plain; charset=ISO-8859-1 Cc: apps-discuss@ietf.org, link-relations@ietf.org X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 00:35:27 -0000 > i tried sending this to barry only, but barryleiba@computer.org does not > seem to be a valid email address, so i'll respond to the list and hope barry > will get in trough the list somehow. Grumble... IEEE (computer.org is a forwarding service of the IEEE Computer Society) has recently started using Postini for filtering, and that's caused sporadic problems, wherein the Postini filtering servers appear sometimes to fail to contact the IEEE address validation servers... and Postini takes the failure to be able to validate the address as meaning that the address is invalid, and bounces the message. It only happens sometimes, and they're not answering my messages asking when it will be fixed (well, or maybe they are, and...). In any case, I got this message both through the list and directly. > thanks for the feedback. i guess i am still a bit confused about the > process. my understanding was that the link-relations experts would provide > feedback, and then it would be sponsored as an RFC. apparently, that's not > how things are working. I'm not entirely sure. Theoretically, at least, they will approve requests for which they are satisfied that the documentation will be published as a stable, public specification. Internet Drafts won't necessarily be that. Those that come through a working group are pretty safe, but individual submissions might or might not go anywhere. In practice, I don't know whether Mark and Julian are looking for an AD sponsor before approving, or simply making their approval contingent on the publication of the document (I'll have to ask them). Anyway, if you have an AD sponsor first (which you now do), we have that covered. > also, please be advised that another similar request > was sent to the link-relations and apps-discuss experts very recently > (http://www.ietf.org/mail-archive/web/apps-discuss/current/msg07356.html) ... > (http://tools.ietf.org/html/draft-wilde-profile-link-03) Yes, I'm happy to sponsor that one as well, and, yes, please also make that Informational after we get feedback from the link-relations list and the DEs. I'll change the state of both document to Publication Requested, and we can start the process. Barry From nathan@webr3.org Tue Oct 9 16:22:38 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33EE911E80EC for ; Tue, 9 Oct 2012 16:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERwYFGGyriS8 for ; Tue, 9 Oct 2012 16:22:37 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 81EEE11E80ED for ; Tue, 9 Oct 2012 16:22:37 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hr7so4640990wib.13 for ; Tue, 09 Oct 2012 16:22:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=8EaKceGA+hbp6EZO1qExVNfLI8b1yMfUcmeYayug1bw=; b=ATt2z4pwQI7W9nQM7rdMCL1oUSv1XYk77punMT6oTinoOg1MuxqXeWv5Nh5R046HrG IjoVqT1TsyeT/isUN8TLOB1mYrvWS98sqGRaXlJMdRvxWSxjmyx83/+oOGAwAnYbp7VD IDyqWxGwqCZM6re+6Vtxe79zZuAqivC03FZzXC6vWryNi+zl6QPpeDZIgf7Z7Ng67clX 6PE2/+eBtySkJ5+DtF2FcOAE95okZ0FGyKUOYdQ9cNs+tJSX+bllhKiw4Z7sg2hqttC9 1sVDH3B7KWAORCEsKXlIAvIagNHV8Y3BSxzkzbBq7BOxvD04whGcV+bWMK34nBbiayED e+BA== Received: by 10.180.96.129 with SMTP id ds1mr8088000wib.17.1349824956540; Tue, 09 Oct 2012 16:22:36 -0700 (PDT) Received: from [172.19.233.133] (host86-141-250-6.range86-141.btcentralplus.com. [86.141.250.6]) by mx.google.com with ESMTPS id q7sm30808841wiy.11.2012.10.09.16.22.35 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 09 Oct 2012 16:22:35 -0700 (PDT) Message-ID: <5074B197.9050101@webr3.org> Date: Wed, 10 Oct 2012 00:21:59 +0100 From: Nathan Organization: webr3 User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Erik Wilde Subject: Re: [rest-discuss] request to register 'describes' link relation (http://tools.ietf.org/html/draft-wilde-describes-link-01) References: <507486FE.2050601@berkeley.edu> In-Reply-To: <507486FE.2050601@berkeley.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmVgkHMsHQ1Idcu5CE5k+ZZzvXytfoSTeSM+pRvznPtJdjoeT/zsTGHS3UliYJscIdb4Asr X-Mailman-Approved-At: Tue, 09 Oct 2012 22:58:35 -0700 Cc: hypermedia-web@googlegroups.com, LDP WG , REST-Discuss , "apps-discuss@ietf.org application-layer protocols" , link-relations@ietf.org X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: nathan@webr3.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 23:22:38 -0000 Erik Wilde wrote: > dear link-relations experts, > > this is a request to register 'describes' in the IANA link relations > registry established by RFC 5988. the latest draft of the registration > document is available at > http://tools.ietf.org/html/draft-wilde-describes-link-01, and the last > version announced on a variety of mailing lists has not generated any > feedback asking for changes. > > should the registration request be accepted, my understanding is that > the draft registration document will be forwarded to IANA for > registration by a designated expert. > > thanks a lot and kind regards, Looks good and most useful, is it worth mentioning anywhere that this inverse relations(describes being the inverse of describedby) is now needed due to @rev falling out of fashion? It may help explain why describes wasn't defined by powder in the first instance. Best and KUTGW, Nathan From jasnell@gmail.com Tue Oct 9 17:10:04 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C86C11E80EE; Tue, 9 Oct 2012 17:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.948 X-Spam-Level: X-Spam-Status: No, score=-3.948 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8AnSBHPlfDh; Tue, 9 Oct 2012 17:10:03 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id C8B6D21F855D; Tue, 9 Oct 2012 17:10:02 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so3459607wgb.13 for ; Tue, 09 Oct 2012 17:10:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Q4iZghSU7G2jse4oMNUEPN/KnS/j3Sdg3lACmtI6tY8=; b=DVbMClyFzAMzqGUQSHuUAjTLpalqx7QD+YcDZd7ySEjV1aDf/rQsZrm4dCbHGhFqer 0NO8Q4IlUF7CqMALI7X6lxp0UdRS9W3K//kfEc1NZ8GxWMEqBPGA8UhaYH8hOJ9QFza0 NZ+A0K/+o5uqH/ySWTwndWFdLKpo9WMIzu6KLpZqhMCrsHCwvcQAmozK+vXml3ULK7EO 9/GU0ZxdnQz6Aa8IUYcDQN0zoG5BIlQXVp7oPGTyGkP2L3j6CrBNPvqi/39BM5Hea1XW WRFXVBpW6dmhQHq7iN6aUY4zBVBIXITdlkuVJPKWYQhhrNfF9ewrKI8LttsOiPhWFKBc +kLA== Received: by 10.180.80.104 with SMTP id q8mr8406906wix.6.1349827801901; Tue, 09 Oct 2012 17:10:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.182.4 with HTTP; Tue, 9 Oct 2012 17:09:41 -0700 (PDT) In-Reply-To: References: <507486FE.2050601@berkeley.edu> From: James M Snell Date: Tue, 9 Oct 2012 17:09:41 -0700 Message-ID: Subject: Re: [apps-discuss] request to register 'describes' link relation (http://tools.ietf.org/html/draft-wilde-describes-link-01) To: Barry Leiba Content-Type: multipart/alternative; boundary=f46d04428eaca3e9b804cba94633 X-Mailman-Approved-At: Tue, 09 Oct 2012 22:58:35 -0700 Cc: Erik Wilde , apps-discuss@ietf.org, link-relations@ietf.org X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 00:10:04 -0000 --f46d04428eaca3e9b804cba94633 Content-Type: text/plain; charset=UTF-8 Sticking my hand up and hoping to get some similar treatment for: http://www.ietf.org/id/draft-snell-additional-link-relations-05.txt This one has been there for a while. I followed the same advice you just gave dret and changed it to informational and cleaned up the normative references. Pretty basic draft. - James On Tue, Oct 9, 2012 at 4:40 PM, Barry Leiba wrote: > [I'm removing the non-IETF groups from the distribution list.] > > > this is a request to register 'describes' in the IANA link relations > > registry established by RFC 5988. the latest draft of the registration > > document is available at > > http://tools.ietf.org/html/draft-wilde-describes-link-01, and the last > > version announced on a variety of mailing lists has not generated any > > feedback asking for changes. > > I'll let the folks on the link-relations list respond to the > suitability of the specification for documenting a useful link > relation. I have just a couple of process points: > > 1. In order for the registration to be done, this document will have > to be published somewhere that will satisfy the Designated Expert as > being a stable reference. That probably means that you'll want this > to be an RFC, so you need to be sorting out how that will happen. > Happily, I'm willing to sponsor this as an AD-sponsored individual > submission, if the link-relations folks agree that we should register > this. > > 2. I don't think this should be Standards Track, though (and it > doesn't need to be in order to register the link relation and to be > the reference documentation for it). I would prefer that you make it > Informational, change the "SHOULD" to "should" in the Security > Considerations, and remove Section 2 and the normative reference to > RFC 2119. (This can wait until after the feedback from the > link-relations mailing list.) > > Barry, Applications AD > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --f46d04428eaca3e9b804cba94633 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sticking my hand up and hoping to get = some similar treatment for:=C2=A0


This one has been there for a while. I followed = the same advice you just gave dret and changed it to informational and clea= ned up the normative references. Pretty basic draft.

- James

On Tue, Oct 9, 2012 at 4:40 PM, Barry Leiba <barryleiba@computer.o= rg> wrote:
[I'm removing the non-IETF groups from t= he distribution list.]

> this is a request to register 'describes' in the IANA link rel= ations
> registry established by RFC 5988. the latest draft of the registration=
> document is available at
> http://tools.ietf.org/html/draft-wilde-describes-link-01, and the last
> version announced on a variety of mailing lists has not generated any<= br> > feedback asking for changes.

I'll let the folks on the link-relations list respond to the
suitability of the specification for documenting a useful link
relation. =C2=A0I have just a couple of process points:

1. In order for the registration to be done, this document will have
to be published somewhere that will satisfy the Designated Expert as
being a stable reference. =C2=A0That probably means that you'll want th= is
to be an RFC, so you need to be sorting out how that will happen.
Happily, I'm willing to sponsor this as an AD-sponsored individual
submission, if the link-relations folks agree that we should register
this.

2. I don't think this should be Standards Track, though (and it
doesn't need to be in order to register the link relation and to be
the reference documentation for it). =C2=A0I would prefer that you make it<= br> Informational, change the "SHOULD" to "should" in the S= ecurity
Considerations, and remove Section 2 and the normative reference to
RFC 2119. =C2=A0(This can wait until after the feedback from the
link-relations mailing list.)

Barry, Applications AD
___________________________________= ____________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--f46d04428eaca3e9b804cba94633-- From jasnell@gmail.com Tue Oct 9 17:26:19 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1648B1F0C4C; Tue, 9 Oct 2012 17:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.579 X-Spam-Level: X-Spam-Status: No, score=-4.579 tagged_above=-999 required=5 tests=[AWL=-0.981, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E99rXjmHThLF; Tue, 9 Oct 2012 17:26:18 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id E6D081F0C5C; Tue, 9 Oct 2012 17:26:17 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hr7so4677384wib.13 for ; Tue, 09 Oct 2012 17:26:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=aosZmi0ChYieWanbQEsMnIRKZPKachXoF7/SRVmppco=; b=iEwnJWPbULphMgWsE4os2TMV+sn8hnri5qFmO2i4nxfFkvy76MRa8liF6rKmdLqPvp Skl+wLZ7bf8qHEV8xenHxCD4ygU2HzXbzQCBuvusEZpKdQuv4C82srgjP1uRki5e/UPk medPA82kzC55XoqRZLE7SASxYicpCCLt9Gm6Sr0rWYViFI8tGcaKdqbEKjAF2CMNlNyZ QmiNwr1geQXmzG+cGZU+MrFsnoj2oY301Xy0GuVCBRa+14Hu/pr0LT7vJF1oBRF/rBDV 9GHtvvHdnB1sncn2X2DlsxoZ51ocDxZFDME7fMPvYE4XtItGkkEHSvGzehfXBAa1i/vB oxeg== Received: by 10.216.204.139 with SMTP id h11mr13104213weo.128.1349828776896; Tue, 09 Oct 2012 17:26:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.182.4 with HTTP; Tue, 9 Oct 2012 17:25:56 -0700 (PDT) In-Reply-To: References: <507486FE.2050601@berkeley.edu> From: James M Snell Date: Tue, 9 Oct 2012 17:25:56 -0700 Message-ID: Subject: Re: [apps-discuss] request to register 'describes' link relation (http://tools.ietf.org/html/draft-wilde-describes-link-01) To: Barry Leiba Content-Type: multipart/alternative; boundary=0016e6d589e1c12a7004cba9800b X-Mailman-Approved-At: Tue, 09 Oct 2012 22:58:35 -0700 Cc: apps-discuss@ietf.org, link-relations@ietf.org X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 00:26:19 -0000 --0016e6d589e1c12a7004cba9800b Content-Type: text/plain; charset=UTF-8 Ok... given that I just rev'd the draft and that's a pretty editorial change, let's hold off on that one until the final edit. I'd say this one is pretty much done and ready for a last call. Assuming everything goes through with that, I can make that section number change in the templates... - James On Tue, Oct 9, 2012 at 5:19 PM, Barry Leiba wrote: > > Sticking my hand up and hoping to get some similar treatment for: > > > > http://www.ietf.org/id/draft-snell-additional-link-relations-05.txt > > > > This one has been there for a while. I followed the same advice you just > > gave dret and changed it to informational and cleaned up the normative > > references. Pretty basic draft. > > Indeed. I suggest that you change the references in each template to > include the section number -- not that the document is long enough to > really matter, but I very much like the cleanliness of it. For > example: > > o Relation Name: about > o Description: Refers to a resource that is the subject of the > link's context. > o Reference: This specification, Section 2. > > Link-relations folk, consider this a formal request for review of the > five relations in the above draft. After comments here, I'll send the > document out for IETF last call. > > Barry > --0016e6d589e1c12a7004cba9800b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ok... given that I just rev'd the = draft and that's a pretty editorial change, let's hold off on that = one until the final edit. I'd say this one is pretty much done and read= y for a last call. Assuming everything goes through with that, I can make t= hat section number change in the templates...=C2=A0

- James

On Tu= e, Oct 9, 2012 at 5:19 PM, Barry Leiba <barryleiba@computer.org&= gt; wrote:
> Sticking my hand up a= nd hoping to get some similar treatment for:
>
> =C2=A0 http://www.ietf.org/id/draft-snell-addit= ional-link-relations-05.txt
>
> This one has been there for a while. I followed the same advice you ju= st
> gave dret and changed it to informational and cleaned up the normative=
> references. Pretty basic draft.

Indeed. =C2=A0I suggest that you change the references in each templa= te to
include the section number -- not that the document is long enough to
really matter, but I very much like the cleanliness of it. =C2=A0For
example:

=C2=A0 =C2=A0o =C2=A0Relation Name: about
=C2=A0 =C2=A0o =C2=A0Description: Refers to a resource that is the subject = of the
=C2=A0 =C2=A0 =C2=A0 link's context.
=C2=A0 =C2=A0o =C2=A0Reference: This specification, Section 2.

Link-relations folk, consider this a formal request for review of the
five relations in the above draft. =C2=A0After comments here, I'll send= the
document out for IETF last call.

Barry

--0016e6d589e1c12a7004cba9800b-- From dret@berkeley.edu Tue Oct 9 23:11:45 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 230E121F8587; Tue, 9 Oct 2012 23:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.351 X-Spam-Level: X-Spam-Status: No, score=-6.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id agvmrXL++KeZ; Tue, 9 Oct 2012 23:11:44 -0700 (PDT) Received: from cm02fe.IST.Berkeley.EDU (cm02fe.IST.Berkeley.EDU [169.229.218.143]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8E421F8582; Tue, 9 Oct 2012 23:11:44 -0700 (PDT) Received: from rrcs-24-43-215-50.west.biz.rr.com ([24.43.215.50] helo=dretair.local) by cm02fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1TLpWA-0000nU-8m; Tue, 09 Oct 2012 23:11:43 -0700 Message-ID: <5075119A.1020104@berkeley.edu> Date: Tue, 09 Oct 2012 20:11:38 -1000 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: nathan@webr3.org Subject: Re: [rest-discuss] request to register 'describes' link relation (http://tools.ietf.org/html/draft-wilde-describes-link-01) References: <507486FE.2050601@berkeley.edu> <5074B197.9050101@webr3.org> In-Reply-To: <5074B197.9050101@webr3.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: hypermedia-web@googlegroups.com, LDP WG , REST-Discuss , "apps-discuss@ietf.org application-layer protocols" , link-relations@ietf.org X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 06:11:45 -0000 hello nathan. On 2012-10-09 13:21 , Nathan wrote: > Looks good and most useful, is it worth mentioning anywhere that this > inverse relations(describes being the inverse of describedby) is now > needed due to @rev falling out of fashion? It may help explain why > describes wasn't defined by powder in the first instance. honestly, i think such a comment would probably confuse more people than it would help. @rev never was a popular idea to begin with and only part of relatively few vocabularies. cheers, dret. -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From dret@berkeley.edu Wed Oct 10 00:02:20 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB4121F8742; Wed, 10 Oct 2012 00:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.413 X-Spam-Level: X-Spam-Status: No, score=-6.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CdPRAlSq2jO; Wed, 10 Oct 2012 00:02:19 -0700 (PDT) Received: from cm02fe.IST.Berkeley.EDU (cm02fe.IST.Berkeley.EDU [169.229.218.143]) by ietfa.amsl.com (Postfix) with ESMTP id B10F521F8735; Wed, 10 Oct 2012 00:02:19 -0700 (PDT) Received: from rrcs-24-43-239-58.west.biz.rr.com ([24.43.239.58] helo=dretair.local) by cm02fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1TLqJ8-0007vN-7S; Wed, 10 Oct 2012 00:02:19 -0700 Message-ID: <50751D76.9000908@berkeley.edu> Date: Tue, 09 Oct 2012 21:02:14 -1000 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Barry Leiba Subject: Re: [apps-discuss] request to register 'describes' link relation (http://tools.ietf.org/html/draft-wilde-describes-link-01) References: <507486FE.2050601@berkeley.edu> <5074BF1F.7030608@berkeley.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org, link-relations@ietf.org X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 07:02:20 -0000 hello barry. On 2012-10-09 14:35 , Barry Leiba wrote: > In practice, I don't know whether Mark and Julian are looking for an > AD sponsor before approving, or simply making their approval > contingent on the publication of the document (I'll have to ask them). > Anyway, if you have an AD sponsor first (which you now do), we have > that covered. great, thanks again and for now, that means we have to wait for the link-relations experts to respond and hear what their feedback is. >> also, please be advised that another similar request >> was sent to the link-relations and apps-discuss experts very recently >> (http://www.ietf.org/mail-archive/web/apps-discuss/current/msg07356.html) > ... >> (http://tools.ietf.org/html/draft-wilde-profile-link-03) > Yes, I'm happy to sponsor that one as well, and, yes, please also make > that Informational after we get feedback from the link-relations list > and the DEs. > I'll change the state of both document to Publication Requested, and > we can start the process. just to make sure everything goes as it should: for now, i'll adjust my local copies of the next versions of both drafts. as soon as we hear from the link-relations experts, i can publish new versions incorporating the changes making the drafts informational, and any changes requested by the experts. thanks and cheers, dret. -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From algermissen1971@mac.com Wed Oct 10 03:01:26 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D302B21F87BC for ; Wed, 10 Oct 2012 03:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.799 X-Spam-Level: X-Spam-Status: No, score=-6.799 tagged_above=-999 required=5 tests=[AWL=-3.800, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BvsZiO5D2NWC for ; Wed, 10 Oct 2012 03:01:26 -0700 (PDT) Received: from nk11p03mm-asmtp006.mac.com (nk11p03mm-asmtp006.mac.com [17.158.232.41]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD4F21F87B8 for ; Wed, 10 Oct 2012 03:01:25 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [10.90.131.173] ([87.253.171.222]) by nk11p03mm-asmtp006.mac.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Jan 3 2012)) with ESMTPSA id <0MBO00MHW9690BB0@nk11p03mm-asmtp006.mac.com> for link-relations@ietf.org; Wed, 10 Oct 2012 10:01:23 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855,1.0.431,0.0.0000 definitions=2012-10-10_03:2012-10-10, 2012-10-10, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1210100047 From: Jan Algermissen Subject: New link relations Date: Wed, 10 Oct 2012 12:01:23 +0200 Message-id: <9B9884DB-E245-42B8-B6E0-540B97B5A756@mac.com> To: link-relations@ietf.org X-Mailer: Apple Mail (2.1283) X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 10:01:26 -0000 Erik and James, I agree with Barry's remark on adding the section number to the registration information. I don't have any issues with the three drafts, but I have an itch that I should scan the registry and the drafts for semantic overlap. I'll do that and get back to you. I am wondering a little whether we are re-inventing RDF/RDFS and Dublin Core as link relations here. Two questions: - How to draw the line what of the core RDF&friends semantics make a useful link relation - Is the probably a way of dealing with 'linked data' in HTTP messages? Just asking... Jan From Peter.Rushforth@NRCan-RNCan.gc.ca Wed Oct 10 06:53:05 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B646C21F8748; Wed, 10 Oct 2012 06:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANBCBe5rbiNz; Wed, 10 Oct 2012 06:53:05 -0700 (PDT) Received: from nrcan.gc.ca (s-bsc-edge1.nrcan.gc.ca [132.156.238.13]) by ietfa.amsl.com (Postfix) with ESMTP id A08C121F8607; Wed, 10 Oct 2012 06:53:04 -0700 (PDT) Received: from S-BSC-CAS1.nrn.nrcan.gc.ca (132.156.238.11) by S-BSC-EDGE1.nrcan.gc.ca (132.156.238.13) with Microsoft SMTP Server (TLS) id 14.2.318.1; Wed, 10 Oct 2012 09:53:03 -0400 Received: from S-BSC-MBX4.nrn.nrcan.gc.ca ([169.254.4.52]) by S-BSC-CAS1.nrn.nrcan.gc.ca ([fe80::c0ec:b772:2bfe:c34d%18]) with mapi id 14.02.0318.001; Wed, 10 Oct 2012 09:53:03 -0400 From: "Rushforth, Peter" To: James M Snell Subject: RE: [apps-discuss] request to register 'describes' link relation (http://tools.ietf.org/html/draft-wilde-describes-link-01) Thread-Topic: [apps-discuss] request to register 'describes' link relation (http://tools.ietf.org/html/draft-wilde-describes-link-01) Thread-Index: AQHNpluEKJYw4tNLl0Go3M06NpAqmpex5SiAgAAIRYCAAKKkgA== Date: Wed, 10 Oct 2012 13:53:02 +0000 Message-ID: <1CD55F04538DEA4F85F3ADF7745464AF1AE768BB@S-BSC-MBX4.nrn.nrcan.gc.ca> References: <507486FE.2050601@berkeley.edu> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [132.156.238.22] Content-Type: multipart/alternative; boundary="_000_1CD55F04538DEA4F85F3ADF7745464AF1AE768BBSBSCMBX4nrnnrca_" MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 10 Oct 2012 07:09:16 -0700 Cc: "apps-discuss@ietf.org" , "link-relations@ietf.org" X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 13:53:05 -0000 --_000_1CD55F04538DEA4F85F3ADF7745464AF1AE768BBSBSCMBX4nrnnrca_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 6. "type" The "type" Link relation can be used to indicate that the context resource is an instance of the resource identified by the target IRI. HTTP/1.1 200 OK Content-Type: text/plain Link: ; type=3D"type" Sally Surely you mean "rel=3D"type" . Peter Rushforth ________________________________ From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of James M Snell Sent: October 9, 2012 20:10 To: Barry Leiba Cc: apps-discuss@ietf.org; link-relations@ietf.org Subject: Re: [apps-discuss] request to register 'describes' link relation (= http://tools.ietf.org/html/draft-wilde-describes-link-01) Sticking my hand up and hoping to get some similar treatment for: http://www.ietf.org/id/draft-snell-additional-link-relations-05.txt This one has been there for a while. I followed the same advice you just ga= ve dret and changed it to informational and cleaned up the normative refere= nces. Pretty basic draft. - James On Tue, Oct 9, 2012 at 4:40 PM, Barry Leiba > wrote: [I'm removing the non-IETF groups from the distribution list.] > this is a request to register 'describes' in the IANA link relations > registry established by RFC 5988. the latest draft of the registration > document is available at > http://tools.ietf.org/html/draft-wilde-describes-link-01, and the last > version announced on a variety of mailing lists has not generated any > feedback asking for changes. I'll let the folks on the link-relations list respond to the suitability of the specification for documenting a useful link relation. I have just a couple of process points: 1. In order for the registration to be done, this document will have to be published somewhere that will satisfy the Designated Expert as being a stable reference. That probably means that you'll want this to be an RFC, so you need to be sorting out how that will happen. Happily, I'm willing to sponsor this as an AD-sponsored individual submission, if the link-relations folks agree that we should register this. 2. I don't think this should be Standards Track, though (and it doesn't need to be in order to register the link relation and to be the reference documentation for it). I would prefer that you make it Informational, change the "SHOULD" to "should" in the Security Considerations, and remove Section 2 and the normative reference to RFC 2119. (This can wait until after the feedback from the link-relations mailing list.) Barry, Applications AD _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss --_000_1CD55F04538DEA4F85F3ADF7745464AF1AE768BBSBSCMBX4nrnnrca_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
6.  "type"

   The "type" Link relation can be used to indicate that the cont=
ext
   resource is an instance of the resource identified by the target IRI.

     HTTP/1.1 200 OK
     Content-Type: text/plain
     Link: <http://example.org/Person/givenName>; type=3D"type"

     Sally
 
Surely= you mean "rel=3D"type" .
 
Peter Rushforth

From: apps-discuss-bounces@ietf.org= [mailto:apps-discuss-bounces@ietf.org] On Behalf Of James M Snell
Sent: October 9, 2012 20:10
To: Barry Leiba
Cc: apps-discuss@ietf.org; link-relations@ietf.org
Subject: Re: [apps-discuss] request to register 'describes' link rel= ation (http://tools.ietf.org/html/draft-wilde-describes-link-01)

Sticking my hand up and hoping to get = some similar treatment for: 


This one has been there for a whi= le. I followed the same advice you just gave dret and changed it to informa= tional and cleaned up the normative references. Pretty basic draft.<= /div>

- James

On Tue, Oct 9, 2012 at 4:40 PM, Barry Leiba <barryleiba= @computer.org> wrote:
[I'm removing the non-IETF groups from the distribution list.]

> this is a request to register 'describes' in the IANA link relations > registry established by RFC 5988. the latest draft of the registration=
> document is available at
> http://tools.ietf.org/html/draft-wilde-describes-link-01, and the last<= br> > version announced on a variety of mailing lists has not generated any<= br> > feedback asking for changes.

I'll let the folks on the link-relations list respond to the
suitability of the specification for documenting a useful link
relation.  I have just a couple of process points:

1. In order for the registration to be done, this document will have
to be published somewhere that will satisfy the Designated Expert as
being a stable reference.  That probably means that you'll want this to be an RFC, so you need to be sorting out how that will happen.
Happily, I'm willing to sponsor this as an AD-sponsored individual
submission, if the link-relations folks agree that we should register
this.

2. I don't think this should be Standards Track, though (and it
doesn't need to be in order to register the link relation and to be
the reference documentation for it).  I would prefer that you make it<= br> Informational, change the "SHOULD" to "should" in the S= ecurity
Considerations, and remove Section 2 and the normative reference to
RFC 2119.  (This can wait until after the feedback from the
link-relations mailing list.)

Barry, Applications AD
_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--_000_1CD55F04538DEA4F85F3ADF7745464AF1AE768BBSBSCMBX4nrnnrca_-- From wmills_92105@yahoo.com Wed Oct 10 06:58:39 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91C6121F853E for ; Wed, 10 Oct 2012 06:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDojbKOd92mb for ; Wed, 10 Oct 2012 06:58:39 -0700 (PDT) Received: from nm21.bullet.mail.sp2.yahoo.com (nm21.bullet.mail.sp2.yahoo.com [98.139.91.91]) by ietfa.amsl.com (Postfix) with ESMTP id 10AC021F8574 for ; Wed, 10 Oct 2012 06:58:39 -0700 (PDT) Received: from [72.30.22.92] by nm21.bullet.mail.sp2.yahoo.com with NNFMP; 10 Oct 2012 13:58:35 -0000 Received: from [98.139.91.37] by tm14.bullet.mail.sp2.yahoo.com with NNFMP; 10 Oct 2012 13:58:35 -0000 Received: from [127.0.0.1] by omp1037.mail.sp2.yahoo.com with NNFMP; 10 Oct 2012 13:58:35 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 125786.81237.bm@omp1037.mail.sp2.yahoo.com Received: (qmail 11780 invoked by uid 60001); 10 Oct 2012 13:58:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1349877514; bh=M7PJCOnfJyMUjtoJwgMAsTHJ+TJnFKqUv+tPYtSda1w=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=CEXL2R8pHgSkPsng672Onz/ZK//1GbWTUz9B2WySTCGAq+9CSg9mq7XTYknd9tow7VqpGJ4zwlbcKS0tEVgLCmZ8vsyvlzALk2XkKj4C0qGg1kmNN1xqQVlNU+MOgCM/tpqseY2hIFN65l2RanPdoZpdDvSBO54QnaMZlO/vGEA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=fJ2DvZQdQtQnjLPJQfqzW5SYWT80PU91brP0cHvblsnH0offcjXTdMAA4gXzTchedlNryc8rOIAM5coN0q9lmLArcQfgRKODk4FjMKgeTJQiEnAx33G7XKkEt6cZVH5IXjamVHBVYYyMEXSECHxzfqJUIvImLQ71yKGW8a/11y0=; X-YMail-OSG: If11RFUVM1nh1ggFXBVUb8yZu8pBf1GDtoZ9RzxGUdYuZ2A MR0MqWN2XbqgMYXBRc7oXahsDbLcPqOYyNMULXNS.jeHDcQJU2zDu3jEt3.W sm.I86hRui_FbmFA_S6di3JnSckq6AyjzHKKGf57ISXqQyChi4GdXv1XJdsm xLGns9itmm9qNWjR7Xsgf.nN4Uxq8nsu3wyt65abfBSqRWA4hBck8jfwbDHR _AvMm.C7A8wlbJF7fyGiP8vMm_NS7veVc1hz9NjyPcEEpTpxHt6_zTO7YkZT gs6wIheYIV30fCO1.yh7LCLFoPuGmEfHOMYlJx5sJKjhS_CLgFN_SegPJmMG 4FyUzNWoIBCCj9xMRIMyTBny6IledrjgfZyGzYWAroLjP2ikiZYlet97W2y0 Pfnq2kstfESj70_Fu57QYOdolp6.3MNE3P6yO9G_gglSWuflOX7HaauSeaCg DkMmtFlaLgP._bM71G8ycBhbUqOBH3CTdAgAYKZD8J6VFvQ-- Received: from [99.31.212.42] by web31805.mail.mud.yahoo.com via HTTP; Wed, 10 Oct 2012 06:58:34 PDT X-Rocket-MIMEInfo: 001.001, UGxlYXNlIHJlZ2lzdGVyIHRoZSBmb2xsb3dpbmcgbGluayByZWxhdGlvbnMgZGV0YWlsZWQgYmVsb3cuCgpUaGFua3MsCgotYmlsbCBtaWxscwoKLS0tLS0tLS0tLS0tLS0tLQoKT0F1dGggMiBBdXRob3JpemF0aW9uIEVuZHBvaW50CgoKwqDCoMKgwqAqIFJlbGF0aW9uIE5hbWU6IG9hdXRoMi1hdXRob3JpemUKwqDCoMKgwqAqIERlc2NyaXB0aW9uOiBBbiBPQXV0aCAyLjAgYXV0aG9yaXphdGlvbiBlbmRwb2ludC4KwqDCoMKgwqAqIFJlZmVyZW5jZTrCoFtJLUQuaWV0Zi1vYXV0aC12Ml0gSGFtbWVyLUxhaGEBMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.450 Message-ID: <1349877514.1410.YahooMailNeo@web31805.mail.mud.yahoo.com> Date: Wed, 10 Oct 2012 06:58:34 -0700 (PDT) From: William Mills Subject: Link Relations registrations for OAuth To: "link-relations@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 10 Oct 2012 07:09:16 -0700 X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 13:58:39 -0000 Please register the following link relations detailed below.=0A=0AThanks,= =0A=0A-bill mills=0A=0A----------------=0A=0AOAuth 2 Authorization Endpoint= =0A=0A=0A=A0=A0=A0=A0* Relation Name: oauth2-authorize=0A=A0=A0=A0=A0* Desc= ription: An OAuth 2.0 authorization endpoint.=0A=A0=A0=A0=A0* Reference:=A0= [I-D.ietf-oauth-v2] Hammer-Lahav, E,=A0Recordon, D=A0and=A0D Hardt, "The OA= uth 2.0 Authorization Framework", Internet-Draft draft-ietf-oauth-v2-26, Ma= y 2012.=0A=A0=A0=A0=A0* Notes: This link type indicates an OAuth 2.0 author= ization endpoint that can be used for user authentication/authorization for= the endpoint providing the link.=0A=A0=A0=A0=A0* Application Data:=A0=0A= =0A=0A=0AOAuth 2 Token Endpoint=0A=0A=0A=A0=A0=A0=A0* Relation Name: oauth2= -token=0A=A0=A0=A0=A0* Description: The OAuth token endpoint used to get to= kens for access.=0A=A0=A0=A0=A0* Reference:=A0[I-D.ietf-oauth-v2] Hammer-La= hav, E,=A0Recordon, D=A0and=A0D Hardt, "The OAuth 2.0 Authorization Framewo= rk", Internet-Draft draft-ietf-oauth-v2-26, May 2012.=0A=A0=A0=A0=A0* Notes= : The OAuth 2.0 token endpoint to be used for obtaining tokens to access th= e endpoint providing the link.=0A=A0=A0=A0=A0* Application Data: This link = type has two link-extensions:=0A=A0grant-types:=0AA space separated list of= OAuth 2.0 grant types (see section 4 of=A0[I-D.ietf-oauth-v2]) that can=A0= =0Abe used at the token endpoint to obtain a token. This is not an exclusiv= e list, it provides a hint=A0=0Ato the application of what SHOULD be valid.= A token endpoint MAY support additional grant=A0=0Atypes not advertised by= a discovery service. The client MAY use this to determine the grant=A0=0At= ypes available for use.=0Atoken-types:=0AA space separated list of OAuth 2.= 0 token types (see section 7.1 of=A0[I-D.ietf-oauth-v2]) that=A0=0Amay be i= ssued by the token endpoint. It is possible for a token endpoint to issue m= ultiple=A0=0Atokens, and types may vary based on scope or other factors. Th= is is not an exclusive list, it=A0=0Aprovides a hint to the application of = what SHOULD be valid, and it MAY be used by a client to=A0=0Adetermine if t= he client supports one or more of the token type(s) available.=0A=0A=0AOAut= h 1.0a Request Initiation Endpoint=0A=A0=A0=A0=A0* Relation Name: oauth-ini= tiate=0A=A0=A0=A0=A0* Description: The OAuth 1.0a request initiation endpoi= nt used to get an access request.=0A=A0=A0=A0=A0* Reference:=A0[RFC5849] Ha= mmer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, April 2010.=A0=0A=A0=A0= =A0=A0* Notes: The OAuth 1.0a endpoint used to initiate the sequence, this = temporary request is what the user approves to grant access to the resource= .=0A=A0=A0=A0=A0* Application Data:=0A=0A=0A=0AOAuth 1.0a Authorization End= point=0A=A0=A0=A0=A0* Relation Name: oauth-authorize=0A=A0=A0=A0=A0* Descri= ption: The OAuth 1.0a authorization endpoint used to approve an access requ= est.=0A=A0=A0=A0=A0* Reference:=A0[RFC5849] Hammer-Lahav, E., "The OAuth 1.= 0 Protocol", RFC 5849, April 2010.=A0=0A=A0=A0=A0=A0* Notes: Expected to be= a user interactive web interface.=0A=A0=A0=A0=A0* Application Data:=0A=0A= =0A=0AToken Endpoint=0A=A0=A0=A0=A0* Relation Name: oauth-token=0A=A0=A0=A0= =A0* Description: The OAuth 1.0a token endpoint used to exchange an approve= d access request for a token.=0A=A0=A0=A0=A0* Reference:=A0[RFC5849] Hammer= -Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, April 2010.=A0=0A=A0=A0=A0= =A0* Notes:=0A=A0=A0=A0=A0* Application Data: From hvdsomp@gmail.com Wed Oct 10 07:19:32 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F6221F8686; Wed, 10 Oct 2012 07:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dPh4TYzSrsmz; Wed, 10 Oct 2012 07:19:31 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id D4A4621F8625; Wed, 10 Oct 2012 07:19:31 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so667897pad.31 for ; Wed, 10 Oct 2012 07:19:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TTMCIp9Y8av1y5HU2WmqpFXSqlPHQoZJmHy331KGSUs=; b=xSRazc/mKkZ471RwrHM5UOHGjYdVBCh2At86RR+9Ie7ckUVgY0MqKJLFnNXR0zfrW8 yF9T2bR+472UYUGEMPhxwsta+PFqG/p8+wliOAZxdAKQiEnhSW6TXXwJz/1oilz4zx1n 1tK15UW5Zpc7epBOI5muiWRM61tmHfRN/EOaUElK/orJVICT8fYnXFs9sLxsiLWdviUN Z1kWiaXNpp1uZMbcqh+lzr/HjL6KV0NivS6Owd6iD8QFzUhsMA9FcdqGc3t4EgCQxXmu vhKRzDAr+D3GL6l76pD17AxFccSQ9tlubWd/BdsieiDFL4inHOxPtBUX44O6uCCdY2XJ NjOg== MIME-Version: 1.0 Received: by 10.68.216.74 with SMTP id oo10mr17556834pbc.92.1349878771374; Wed, 10 Oct 2012 07:19:31 -0700 (PDT) Received: by 10.68.202.168 with HTTP; Wed, 10 Oct 2012 07:19:31 -0700 (PDT) In-Reply-To: References: <507486FE.2050601@berkeley.edu> Date: Wed, 10 Oct 2012 08:19:31 -0600 Message-ID: Subject: Re: [apps-discuss] request to register 'describes' link relation (http://tools.ietf.org/html/draft-wilde-describes-link-01) From: Herbert van de Sompel To: link-relations@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: James M Snell , Barry Leiba , Erik Wilde , apps-discuss@ietf.org X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 14:19:32 -0000 hi all, Since we are at this, I would also like to point out the request to register Memento link relation types, which I submitted August 29 2012: http://www.ietf.org/mail-archive/web/link-relations/current/msg00372.html It was my understanding, from a brief email exchange with Mark Nottingham, that it was possible to reserve a spot in the registry for rel types for which there was not yet an RFC but for which a spec was in the works. In the case of Memento, that is the I-D https://datatracker.ietf.org/doc/draft-vandesompel-memento/. I think this ability is rather essential: Memento rel types are already in use in many applications and it would be rather counter-productive if someone else could register them for some other purpose prior to the Memento I-D reaching RFC status. Cheers Herbert On Tue, Oct 9, 2012 at 6:09 PM, James M Snell wrote: > Sticking my hand up and hoping to get some similar treatment for: > > http://www.ietf.org/id/draft-snell-additional-link-relations-05.txt > > This one has been there for a while. I followed the same advice you just > gave dret and changed it to informational and cleaned up the normative > references. Pretty basic draft. > > - James > > On Tue, Oct 9, 2012 at 4:40 PM, Barry Leiba wrote: >> >> [I'm removing the non-IETF groups from the distribution list.] >> >> > this is a request to register 'describes' in the IANA link relations >> > registry established by RFC 5988. the latest draft of the registration >> > document is available at >> > http://tools.ietf.org/html/draft-wilde-describes-link-01, and the last >> > version announced on a variety of mailing lists has not generated any >> > feedback asking for changes. >> >> I'll let the folks on the link-relations list respond to the >> suitability of the specification for documenting a useful link >> relation. I have just a couple of process points: >> >> 1. In order for the registration to be done, this document will have >> to be published somewhere that will satisfy the Designated Expert as >> being a stable reference. That probably means that you'll want this >> to be an RFC, so you need to be sorting out how that will happen. >> Happily, I'm willing to sponsor this as an AD-sponsored individual >> submission, if the link-relations folks agree that we should register >> this. >> >> 2. I don't think this should be Standards Track, though (and it >> doesn't need to be in order to register the link relation and to be >> the reference documentation for it). I would prefer that you make it >> Informational, change the "SHOULD" to "should" in the Security >> Considerations, and remove Section 2 and the normative reference to >> RFC 2119. (This can wait until after the feedback from the >> link-relations mailing list.) >> >> Barry, Applications AD >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > > > > _______________________________________________ > link-relations mailing list > link-relations@ietf.org > https://www.ietf.org/mailman/listinfo/link-relations > -- Herbert Van de Sompel Digital Library Research & Prototyping Los Alamos National Laboratory, Research Library http://public.lanl.gov/herbertv/ == From barryleiba@gmail.com Wed Oct 10 07:37:53 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4A2F21F87BA; Wed, 10 Oct 2012 07:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.07 X-Spam-Level: X-Spam-Status: No, score=-103.07 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WjGvTKfIIIX1; Wed, 10 Oct 2012 07:37:53 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 138FF21F87B2; Wed, 10 Oct 2012 07:37:52 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so563443vbb.31 for ; Wed, 10 Oct 2012 07:37:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=iDGweSH8upfEeCra7v9Q7Q8/GlcW+Sqxo+XoLIxx7bQ=; b=j/e6XdEnjMg56jTPtyEUvytqWU3Hr+jVJEHmSTUYOXOdKb8ImTqDIExhFGvuSvs5Li Rre+4XmYjqOQChgWbZYQB4flRk7RTatFbvEf/SGVTygyFkqiJDxn8RBAin5wDIJAy1MJ AIFAmEnc24t0tPjZcqAu2P0o1eBqlBKVMUEBPnf3t3SvtqFMnbhhCqGl2NLFSr67ycU7 bUt0wjoSv0AvrX2V9CDtK/lTJ7aNNcBGEHW5Fvn35DMLABcrPP5Ie8LcKhMxGVVntybj bv0ZeFmqvUnr9HB/iBE3rw5ARIv+v5dgJRyW8/y0iRmV/0bme0MjHvMrkcXS5k8pHv7i CysQ== MIME-Version: 1.0 Received: by 10.52.65.51 with SMTP id u19mr11316814vds.3.1349879872447; Wed, 10 Oct 2012 07:37:52 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.59.5.72 with HTTP; Wed, 10 Oct 2012 07:37:52 -0700 (PDT) In-Reply-To: References: <507486FE.2050601@berkeley.edu> Date: Wed, 10 Oct 2012 10:37:52 -0400 X-Google-Sender-Auth: jn1Zou6XtlBrUB7MvB-qVXBpTvM Message-ID: Subject: Re: [apps-discuss] request to register 'describes' link relation (http://tools.ietf.org/html/draft-wilde-describes-link-01) From: Barry Leiba To: Herbert van de Sompel Content-Type: text/plain; charset=ISO-8859-1 Cc: apps-discuss@ietf.org, link-relations@ietf.org X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 14:37:53 -0000 > Since we are at this, I would also like to point out the request to > register Memento link relation types, which I submitted August 29 > 2012: > > http://www.ietf.org/mail-archive/web/link-relations/current/msg00372.html > > It was my understanding, from a brief email exchange with Mark > Nottingham, that it was possible to reserve a spot in the registry for > rel types for which there was not yet an RFC but for which a spec was > in the works. In the case of Memento, that is the I-D > https://datatracker.ietf.org/doc/draft-vandesompel-memento/. I think > this ability is rather essential: Memento rel types are already in use > in many applications and it would be rather counter-productive if > someone else could register them for some other purpose prior to the > Memento I-D reaching RFC status. I think you needn't worry here. Your document is submitted to the Independent Stream and is under review by the ISE. The designated experts are aware of your registration request, and won't be approving someone else's registration of the same name. The actual registration will be made by IANA when the ISE publishes the document. I'm currently discussing with the designated experts what the tracking process is for these. Perhaps we might make it more visible, so people can know the status of their requests. Barry From julian.reschke@gmx.de Wed Oct 10 08:06:18 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0AA21F8758 for ; Wed, 10 Oct 2012 08:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.343 X-Spam-Level: X-Spam-Status: No, score=-103.343 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhgi0LnVNe4n for ; Wed, 10 Oct 2012 08:06:17 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 58C3921F877D for ; Wed, 10 Oct 2012 08:06:17 -0700 (PDT) Received: (qmail invoked by alias); 10 Oct 2012 15:06:16 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp039) with SMTP; 10 Oct 2012 17:06:16 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19cbosw55FcpipaT2f1b0D4yMVbbonAa5M/sYxSdB SdAHARYeUafebC Message-ID: <50758EE7.1070101@gmx.de> Date: Wed, 10 Oct 2012 17:06:15 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: William Mills Subject: Re: Link Relations registrations for OAuth References: <1349877514.1410.YahooMailNeo@web31805.mail.mud.yahoo.com> In-Reply-To: <1349877514.1410.YahooMailNeo@web31805.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "link-relations@ietf.org" X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 15:06:18 -0000 Hi William, I' afraid it's not *that* easy, see comments inline. On 2012-10-10 15:58, William Mills wrote: > Please register the following link relations detailed below. > > Thanks, > > -bill mills > > ---------------- > > OAuth 2 Authorization Endpoint > > > * Relation Name: oauth2-authorize > * Description: An OAuth 2.0 authorization endpoint. > * Reference: [I-D.ietf-oauth-v2] Hammer-Lahav, E, Recordon, D and D Hardt, "The OAuth 2.0 Authorization Framework", Internet-Draft draft-ietf-oauth-v2-26, May 2012. > * Notes: This link type indicates an OAuth 2.0 authorization endpoint that can be used for user authentication/authorization for the endpoint providing the link. > * Application Data: The reference should point to a document that actually defines the link relation. As far as I can tell, this is not that case here. Either add the actual definition to draft-ietf-oauth-v2, or have a separate document defining it. > > OAuth 2 Token Endpoint > > > * Relation Name: oauth2-token > * Description: The OAuth token endpoint used to get tokens for access. > * Reference: [I-D.ietf-oauth-v2] Hammer-Lahav, E, Recordon, D and D Hardt, "The OAuth 2.0 Authorization Framework", Internet-Draft draft-ietf-oauth-v2-26, May 2012. > * Notes: The OAuth 2.0 token endpoint to be used for obtaining tokens to access the endpoint providing the link. > * Application Data: This link type has two link-extensions: See above. Also: "Application Data" is additional meta data to be added to the registry. What you have here are additional parameters to the link relation, which is something completely different (and also something that I think should be avoided). > grant-types: > A space separated list of OAuth 2.0 grant types (see section 4 of [I-D.ietf-oauth-v2]) that can > be used at the token endpoint to obtain a token. This is not an exclusive list, it provides a hint > to the application of what SHOULD be valid. A token endpoint MAY support additional grant > types not advertised by a discovery service. The client MAY use this to determine the grant > types available for use. > token-types: > A space separated list of OAuth 2.0 token types (see section 7.1 of [I-D.ietf-oauth-v2]) that > may be issued by the token endpoint. It is possible for a token endpoint to issue multiple > tokens, and types may vary based on scope or other factors. This is not an exclusive list, it > provides a hint to the application of what SHOULD be valid, and it MAY be used by a client to > determine if the client supports one or more of the token type(s) available. > > > OAuth 1.0a Request Initiation Endpoint > * Relation Name: oauth-initiate > * Description: The OAuth 1.0a request initiation endpoint used to get an access request. > * Reference: [RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, April 2010. > * Notes: The OAuth 1.0a endpoint used to initiate the sequence, this temporary request is what the user approves to grant access to the resource. > * Application Data: > > > > OAuth 1.0a Authorization Endpoint > * Relation Name: oauth-authorize > * Description: The OAuth 1.0a authorization endpoint used to approve an access request. > * Reference: [RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, April 2010. > * Notes: Expected to be a user interactive web interface. > * Application Data: > > > > Token Endpoint > * Relation Name: oauth-token > * Description: The OAuth 1.0a token endpoint used to exchange an approved access request for a token. > * Reference: [RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, April 2010. > * Notes: > * Application Data: ...again, see above: the reference actually needs to define the link relation (the registry should contain *pointers* to definitions, not the definitions themselves). Best regards, Julian From barryleiba@gmail.com Wed Oct 10 08:12:45 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C661721F87CC for ; Wed, 10 Oct 2012 08:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.069 X-Spam-Level: X-Spam-Status: No, score=-103.069 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6F-ratkRkM-m for ; Wed, 10 Oct 2012 08:12:45 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 49DFE21F86B2 for ; Wed, 10 Oct 2012 08:12:45 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so619686vbb.31 for ; Wed, 10 Oct 2012 08:12:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=8CBSdLYA6RVjSkq6fU9sPOsoVEWrlGC5irfopyDHeMw=; b=pxFwvAg0MAT2rGIl701A/eZakj1eh0X8Y9utRfPNL+rwzKZ6+88IbVYSS6RvTi+9gP RPJ5TX1Zqy+YCZBDqeVhtKk8UjyP75gIStftMaoB6oaaK/LmdZiVJ1yq6rozGHXVUbxL ynnFUlpljABXRxARuMUow5kHoA+KfaTpsoHOATH2ceMSwGLXXFyEH/V1AP2KIVkvlcUc lyGin2fo2cXYIVvGwWskGRpx7zxBIwegCPAbWHBgXVcX8SKH6iX6cy8lUk7y5HjNVYXY Rv8DawWcernoUCP8zDmOEpiwj4RwiFajeI+pTZZR4xXN11yoi2pRMmbb146aAsgIAywN 141w== MIME-Version: 1.0 Received: by 10.220.238.148 with SMTP id ks20mr14034038vcb.5.1349881959082; Wed, 10 Oct 2012 08:12:39 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.59.5.72 with HTTP; Wed, 10 Oct 2012 08:12:39 -0700 (PDT) In-Reply-To: <50758FA6.3000708@gmx.de> References: <50758EE7.1070101@gmx.de> <50758FA6.3000708@gmx.de> Date: Wed, 10 Oct 2012 11:12:39 -0400 X-Google-Sender-Auth: u20ah7njwTDns-rWlHrlyLch5KA Message-ID: Subject: Re: Re: Link Relations registrations for OAuth From: Barry Leiba To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Cc: William Mills , link-relations@ietf.org X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 15:12:45 -0000 > I' afraid it's not *that* easy, see comments inline. ... > The reference should point to a document that actually defines the link > relation. As far as I can tell, this is not that case here. > > Either add the actual definition to draft-ietf-oauth-v2, or have a > separate document defining it. Julian, I don't agree, and I'm the one who told him that he should do it this way. The only thing that has to be published in a stable, public document is the reference, not the registration request. Why do you think the registration request needs to be published in an RFC? Barry From julian.reschke@gmx.de Wed Oct 10 08:25:13 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F187921F87BE for ; Wed, 10 Oct 2012 08:25:12 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eaCaPsRC2kek for ; Wed, 10 Oct 2012 08:25:12 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 43BFB21F8501 for ; Wed, 10 Oct 2012 08:25:11 -0700 (PDT) Received: (qmail invoked by alias); 10 Oct 2012 15:25:06 -0000 Received: from unknown (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp004) with SMTP; 10 Oct 2012 17:25:06 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19fYeIF2Yhf0S2VC7sUIeCi5DuPbrWe+w/jV05IS3 gXDKL6zXgh3w6x Message-ID: <50759349.5070001@gmx.de> Date: Wed, 10 Oct 2012 17:24:57 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Barry Leiba Subject: Re: Link Relations registrations for OAuth References: <50758EE7.1070101@gmx.de> <50758FA6.3000708@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: William Mills , link-relations@ietf.org X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 15:25:13 -0000 On 2012-10-10 17:12, Barry Leiba wrote: >> I' afraid it's not *that* easy, see comments inline. > ... >> The reference should point to a document that actually defines the link >> relation. As far as I can tell, this is not that case here. >> >> Either add the actual definition to draft-ietf-oauth-v2, or have a >> separate document defining it. > > Julian, I don't agree, and I'm the one who told him that he should do > it this way. > > The only thing that has to be published in a stable, public document > is the reference, not the registration request. > > Why do you think the registration request needs to be published in an RFC? > ... I didn't say that. What needs to be published in an RFC (or stable spec...) is the actual description of the link relation. Best regards, Julian From barryleiba@gmail.com Wed Oct 10 08:32:47 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9C2021F864A for ; Wed, 10 Oct 2012 08:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.068 X-Spam-Level: X-Spam-Status: No, score=-103.068 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tm4qIwIkIAzz for ; Wed, 10 Oct 2012 08:32:47 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3046F21F8584 for ; Wed, 10 Oct 2012 08:32:47 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so1035785vcb.31 for ; Wed, 10 Oct 2012 08:32:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=FfSW/eBjGhcrgJywIo/4o+YO+0apEoKY+8bWFohg+Nk=; b=mRY95WjP4lRmBCRvVD6WezpXXYB8OQTOcjnKiqZxqibJqADPwUC2AVK7cO/C/VPXHK g+qiO7R5Ml8rU67DyGPv46wAYtpT91BUzBNuu1zLbGT42i3zTi0h7M6pLDrUq6v2ZWoF Od0y+vECJ7hhRXBnI0b3tq3tRzRM/JaLXOvWRXSWbOdzIVm6PPnwi5JDQocWyvU0JMq+ 5j0Av+QGpXwC3TbReZKfP/dj6boU9TYM54B54kZ6Rydky/GNMvAT+Ugtze7/cnHYgj/G KaLkLNwcULsnMcF3uyyRWh9Wttar7nXmBRl/4u/8hmOCzuwO+pCYqIC84FhaEOmMBxx+ nctg== MIME-Version: 1.0 Received: by 10.58.209.73 with SMTP id mk9mr14623335vec.25.1349883165507; Wed, 10 Oct 2012 08:32:45 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.59.5.72 with HTTP; Wed, 10 Oct 2012 08:32:45 -0700 (PDT) In-Reply-To: <50759349.5070001@gmx.de> References: <50758EE7.1070101@gmx.de> <50758FA6.3000708@gmx.de> <50759349.5070001@gmx.de> Date: Wed, 10 Oct 2012 11:32:45 -0400 X-Google-Sender-Auth: roqvFp7Ye9ThpgEqIKWVmVZKsuM Message-ID: Subject: Re: Link Relations registrations for OAuth From: Barry Leiba To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Cc: William Mills , link-relations@ietf.org X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 15:32:47 -0000 > What needs to be published in an RFC (or stable spec...) is the actual > description of the link relation. Ah. IOW, you're saying that the OAuth specs describe OAuth, but not the link relation, so they are not the correct references to use. I'll buy that. Which means that my too-quick advice to Bill needs to be rescinded, and the correct advice is something like this: ------------------------ > OAuth 2 Authorization Endpoint > > * Relation Name: oauth2-authorize > * Description: An OAuth 2.0 authorization endpoint. > * Reference: [I-D.ietf-oauth-v2] > * Notes: This link type indicates an OAuth 2.0 authorization endpoint > that can be used for user authentication/authorization for the endpoint providing the link. > * Application Data: draft-ietf-oauth-v2 is not a correct and useful reference for this link relation. You'll need to go back to your original document and use it to document the link relation specifically, and in THAT documentation refer to draft-ietf-oauth-v2 as appropriate. Then that document can register the link relation with a reference to itself, which will in turn have a reference to draft-ietf-oauth-v2. And similarly for the other four link relations you're requesting. ------------------------ Julian, does that seem right? Bill, that document can be Informational, and can either be AD-sponsored or go through the Independent Stream. Barry From julian.reschke@gmx.de Wed Oct 10 08:39:19 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13EEB21F87CC for ; Wed, 10 Oct 2012 08:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.292 X-Spam-Level: X-Spam-Status: No, score=-103.292 tagged_above=-999 required=5 tests=[AWL=-0.693, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLSjeufyC+NS for ; Wed, 10 Oct 2012 08:39:18 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id CEEAB21F87CA for ; Wed, 10 Oct 2012 08:39:17 -0700 (PDT) Received: (qmail invoked by alias); 10 Oct 2012 15:39:16 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp035) with SMTP; 10 Oct 2012 17:39:16 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/c9vFM0xncclkAGvBsZZpLRGoM7dO7QidVtAf5qf fzd2/YjvlJXilI Message-ID: <507596A3.5060504@gmx.de> Date: Wed, 10 Oct 2012 17:39:15 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Barry Leiba Subject: Re: Link Relations registrations for OAuth References: <50758EE7.1070101@gmx.de> <50758FA6.3000708@gmx.de> <50759349.5070001@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: William Mills , link-relations@ietf.org X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 15:39:19 -0000 On 2012-10-10 17:32, Barry Leiba wrote: >> What needs to be published in an RFC (or stable spec...) is the actual >> description of the link relation. > > Ah. IOW, you're saying that the OAuth specs describe OAuth, but not > the link relation, so they are not the correct references to use. > I'll buy that. Exactly. > Which means that my too-quick advice to Bill needs to be rescinded, > and the correct advice is something like this: > > ------------------------ >> OAuth 2 Authorization Endpoint >> >> * Relation Name: oauth2-authorize >> * Description: An OAuth 2.0 authorization endpoint. >> * Reference: [I-D.ietf-oauth-v2] >> * Notes: This link type indicates an OAuth 2.0 authorization endpoint >> that can be used for user authentication/authorization for the endpoint providing the link. >> * Application Data: > > draft-ietf-oauth-v2 is not a correct and useful reference for this > link relation. You'll need to go back to your original document and > use it to document the link relation specifically, and in THAT > documentation refer to draft-ietf-oauth-v2 as appropriate. Then that > document can register the link relation with a reference to itself, > which will in turn have a reference to draft-ietf-oauth-v2. > > And similarly for the other four link relations you're requesting. > ------------------------ > > Julian, does that seem right? > > Bill, that document can be Informational, and can either be > AD-sponsored or go through the Independent Stream. Absolutely. In case these link relations have the OAuth WG consensus, it might also be possible to add them to the OAuth spec itself (not sure about timing & scope, though). Best regard, Julian From barryleiba@gmail.com Wed Oct 10 08:41:59 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5BB21F86C5 for ; Wed, 10 Oct 2012 08:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.066 X-Spam-Level: X-Spam-Status: No, score=-103.066 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WI+k4FxU3lh3 for ; Wed, 10 Oct 2012 08:41:58 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 87ADB21F864A for ; Wed, 10 Oct 2012 08:41:58 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so665150vbb.31 for ; Wed, 10 Oct 2012 08:41:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=3mwcmsWn1wOHMCBtmoSnrKUuND66BXSUHRrUy0+Mwlk=; b=oiaes7Z+VtjNTd72QMEeYo8rqTl+KdmUm/vjUGuL4xIi9B7acPjEXHOElgmxclO84q RpyEHRGOlD4X8jzgvj1ZfNJVNV7Y6Lbs5b/iwE8HtgzFU3Aoz2PdERQTrJP8GrH5vEgk z1WJGSMUWPIW4qvtDbb7B7EdA5P9K3tVnyAvUBcQ+IjK01L+ObxvAIKl1G3OIIXSGVNm ndjXZ9QEjiAa3JSWZ9obcclF6pMM3PektaCQqBmctpVfucv/5XWYwTF5KdsMf8rRGi3q 2qXBCrkdMk1ScjcF3vi0zCgaPWPOuxxTHov6Szh+TleRHCjiISOJwX9HYKL90yfCH8WN OCdA== MIME-Version: 1.0 Received: by 10.58.162.130 with SMTP id ya2mr7376814veb.2.1349883718032; Wed, 10 Oct 2012 08:41:58 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.59.5.72 with HTTP; Wed, 10 Oct 2012 08:41:57 -0700 (PDT) In-Reply-To: <507596A3.5060504@gmx.de> References: <50758EE7.1070101@gmx.de> <50758FA6.3000708@gmx.de> <50759349.5070001@gmx.de> <507596A3.5060504@gmx.de> Date: Wed, 10 Oct 2012 11:41:57 -0400 X-Google-Sender-Auth: zGlubAquBE-acLo54LIC2QutiEI Message-ID: Subject: Re: Link Relations registrations for OAuth From: Barry Leiba To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Cc: William Mills , link-relations@ietf.org X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 15:41:59 -0000 >> Julian, does that seem right? >> >> Bill, that document can be Informational, and can either be >> AD-sponsored or go through the Independent Stream. > > Absolutely. Great. Then, Bill, I'm sorry I initially steered you wrong, but the correct answer is that you need to beef up the document a bit, with a section describing each link relation. Then the document will not just be nothing more than an IANA Considerations section, but will actually have some documentation in it. > In case these link relations have the OAuth WG consensus, it might also be > possible to add them to the OAuth spec itself (not sure about timing & > scope, though). No, that's not happening. The OAuth v1 doc is an RFC, and the OAuth v2 doc is in AUTH48 now. b From wmills_92105@yahoo.com Wed Oct 10 09:04:30 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC1F21F8487 for ; Wed, 10 Oct 2012 09:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVfyySADtFS0 for ; Wed, 10 Oct 2012 09:04:28 -0700 (PDT) Received: from nm14-vm2.bullet.mail.ne1.yahoo.com (nm14-vm2.bullet.mail.ne1.yahoo.com [98.138.91.90]) by ietfa.amsl.com (Postfix) with ESMTP id 5737121F847C for ; Wed, 10 Oct 2012 09:04:28 -0700 (PDT) Received: from [98.138.90.56] by nm14.bullet.mail.ne1.yahoo.com with NNFMP; 10 Oct 2012 16:04:20 -0000 Received: from [98.138.89.167] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 10 Oct 2012 16:04:20 -0000 Received: from [127.0.0.1] by omp1023.mail.ne1.yahoo.com with NNFMP; 10 Oct 2012 16:04:20 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 857797.5281.bm@omp1023.mail.ne1.yahoo.com Received: (qmail 26200 invoked by uid 60001); 10 Oct 2012 16:04:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1349885060; bh=jr7nWnJMiTNOU2GrvGwpBFjE2thoSSQpb7Gn+EbLFek=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=RLpVDVOxaY1sqmzvK+3tMq1Aijef/X6RWVu9us5lhoY9POIdJbJ+3Bq7mlbNwpfuVDpwUGf8vUWLARQQv4QJ+k8hMUp5SfMfFbcwwP4YWrlyUxYkKksNsyVyD/RvmcDHiKBcHXTZutMu9dxFfIpG5Vb1mT6+sXAp9NgfNHWZ9vQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=mJ6ZRRgqzKxXBcopayiAQBxjdC5HyA7FTYWThZkihtX4jpOBjZeMZDtp5baUlZgS1A6BGyrEC88yFLzRDEra3ndNrUuew3aSFp+b5R9niwtQC+nUudUngJYH5qINzr4TunluU9VwhZMuVoP1wWshVwJXWIXXINwg/DJ4XqiCpws=; X-YMail-OSG: UtL3UfsVM1lyGrr_G6T9muYvMZ89adqSVWL7q1DqcgXdXZp CcYpuJE3tVsxrAp9GanzmJ7fjwItgkb0B_ni5ZhTmNsfK5qeoZQEKy6Ne._5 7QCGQX.lGmacAivG9rQQrUGDnxKhE.Yf_K_nh7yRGgRsfJdWcRzItP.FZ.eV vql0EQnXcTa_TAwdaJ6n7Yj2qT9fk0.w0fhPEL1NpO2KOyxeA5rKJUUdkJmZ DZMMRvn4hXrMPuwClPG.naVe0B2Vn8dhFluZvJYfPp57Kun_BS88be2goPtu vCZ3oRhP9jfixbjT.5t9ezCef9aur2P5K1O4w2iwhPxg3ea_pAYgAhb9kM8W 5oiaNzToDH4mBxUNECkZBFehS06mXTuozNhiJpXYf.jFdoKbZFRXVwTkzBa8 oA.tvS5xGf.nqstklpZMed8zatnQ.3Kki3gBQc3dC._p8A9o9.ghpHEw.Nj0 Ezvd2sNiMN3zrzmGYsUxLcN_nVQOZ1EeLyLov7WnkJfPbNcWCBIK0B1dA1XK HIDE- Received: from [107.39.1.175] by web31801.mail.mud.yahoo.com via HTTP; Wed, 10 Oct 2012 09:04:19 PDT X-Rocket-MIMEInfo: 001.001, T0ssIEknbGwgYmVlZiB1cCBlYWNoIGxpbmsgcmVsYXRpb24gc2VjdGlvbiBhIGJpdCB3aXRoIGRlc2NyaXB0aXZlIHRleHQuIMKgRWFzaWx5IGRvbmUuCgpJcyB0aGVyZSBhbiBhZHZhbnRhZ2UgdG8gdGhlIEFEIHByb2Nlc3Mgb3IgSW5kZXBlbmRlbnQgU3RyZWFtPyDCoEknbSBoYXBweSB0byBkbyBlaXRoZXIsIGJ1dCBJJ20gbm90IGZhbWlsaWFyIHdpdGggZWl0aGVyIHNvIEkgbmVlZCB0byBrbm93IG5leHQgc3RlcHMgcGxlYXNlLgoKUmVnYXJkcywKCi1iaWxsCgoKLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSABMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.450 References: <50758EE7.1070101@gmx.de> <50758FA6.3000708@gmx.de> <50759349.5070001@gmx.de> Message-ID: <1349885059.24581.YahooMailNeo@web31801.mail.mud.yahoo.com> Date: Wed, 10 Oct 2012 09:04:19 -0700 (PDT) From: William Mills Subject: Re: Link Relations registrations for OAuth To: Barry Leiba , Julian Reschke In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 10 Oct 2012 09:13:28 -0700 Cc: "link-relations@ietf.org" X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 16:04:30 -0000 OK, I'll beef up each link relation section a bit with descriptive text. = =A0Easily done.=0A=0AIs there an advantage to the AD process or Independent= Stream? =A0I'm happy to do either, but I'm not familiar with either so I n= eed to know next steps please.=0A=0ARegards,=0A=0A-bill=0A=0A=0A----- Origi= nal Message -----=0AFrom: Barry Leiba =0ATo: Julia= n Reschke =0ACc: William Mills ; link-relations@ietf.org=0ASent: Wednesday, October 10, 2012 8:32 AM=0A= Subject: Re: Link Relations registrations for OAuth=0A=0A> What needs to be= published in an RFC (or stable spec...) is the actual=0A> description of t= he link relation.=0A=0AAh.=A0 IOW, you're saying that the OAuth specs descr= ibe OAuth, but not=0Athe link relation, so they are not the correct referen= ces to use.=0AI'll buy that.=0A=0AWhich means that my too-quick advice to B= ill needs to be rescinded,=0Aand the correct advice is something like this:= =0A=0A------------------------=0A> OAuth 2 Authorization Endpoint=0A>=0A>= =A0 =A0 * Relation Name: oauth2-authorize=0A>=A0 =A0 * Description: An OAut= h 2.0 authorization endpoint.=0A>=A0 =A0 * Reference: [I-D.ietf-oauth-v2]= =0A>=A0 =A0 * Notes: This link type indicates an OAuth 2.0 authorization en= dpoint=0A>=A0 =A0 =A0 that can be used for user authentication/authorizatio= n for the endpoint providing the link.=0A>=A0 =A0 * Application Data:=0A=0A= draft-ietf-oauth-v2 is not a correct and useful reference for this=0Alink r= elation.=A0 You'll need to go back to your original document and=0Ause it t= o document the link relation specifically, and in THAT=0Adocumentation refe= r to draft-ietf-oauth-v2 as appropriate.=A0 Then that=0Adocument can regist= er the link relation with a reference to itself,=0Awhich will in turn have = a reference to draft-ietf-oauth-v2.=0A=0AAnd similarly for the other four l= ink relations you're requesting.=0A------------------------=0A=0AJulian, do= es that seem right?=0A=0ABill, that document can be Informational, and can = either be=0AAD-sponsored or go through the Independent Stream.=0A=0ABarry= =0A From julian.reschke@gmx.de Wed Oct 10 09:27:57 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7E5121F852E for ; Wed, 10 Oct 2012 09:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.269 X-Spam-Level: X-Spam-Status: No, score=-103.269 tagged_above=-999 required=5 tests=[AWL=-0.670, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dleiLxVo2ucz for ; Wed, 10 Oct 2012 09:27:57 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id BC16B21F84F9 for ; Wed, 10 Oct 2012 09:27:56 -0700 (PDT) Received: (qmail invoked by alias); 10 Oct 2012 16:27:55 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp024) with SMTP; 10 Oct 2012 18:27:55 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+OMHIPps2OjL0fdOdoghyy+k+LY1ie5EFic5J7c7 FL5wxJLkULDaNp Message-ID: <5075A20A.204@gmx.de> Date: Wed, 10 Oct 2012 18:27:54 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: William Mills Subject: Re: Link Relations registrations for OAuth References: <50758EE7.1070101@gmx.de> <50758FA6.3000708@gmx.de> <50759349.5070001@gmx.de> <1349885059.24581.YahooMailNeo@web31801.mail.mud.yahoo.com> In-Reply-To: <1349885059.24581.YahooMailNeo@web31801.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Barry Leiba , "link-relations@ietf.org" X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 16:27:57 -0000 On 2012-10-10 18:04, William Mills wrote: > OK, I'll beef up each link relation section a bit with descriptive text. Easily done. > > Is there an advantage to the AD process or Independent Stream? I'm happy to do either, but I'm not familiar with either so I need to know next steps please. > > Regards, > > -bill > ... I don't think it matters a lot. An AD sponsoring it will probably help process-wise. On the other hand, it would be nice to demonstrate that we don't *need* an AD here, so it would also be nice to test the Independent Stream approach. Best regards, Julian From barryleiba@gmail.com Wed Oct 10 09:38:01 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 523C621F860E for ; Wed, 10 Oct 2012 09:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.065 X-Spam-Level: X-Spam-Status: No, score=-103.065 tagged_above=-999 required=5 tests=[AWL=-0.088, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7wa30jp2vrOg for ; Wed, 10 Oct 2012 09:38:00 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A28A121F8607 for ; Wed, 10 Oct 2012 09:38:00 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so1136182vcb.31 for ; Wed, 10 Oct 2012 09:38:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=6LD0X8tHASIVJUufMEl1+/AQXkte6QlSefI58rOIc5w=; b=o6nJTDSlrr1zFt77RzCFvHpBhAB3/cRiZvnEhnogqjJZcCGBZyfNIqieNwwDKBueRl dZ7pqq3VF89NRAk5MphHb2OxlFau9zA7vkXwcz9axpRtq29ms1dOxuJWas2Cm3EoBvKc twgsZnAX++FjZQHljGYdAxnx63O4K87NqSxOAkEMyDuOf9Meb2J9yIS9ifs9tBJvMBeQ z6Gx6yRIVvGCv4k0/x6HdD6dhS+dcfTsL3rPV8bHpWD0CJCNpcRnxjKjn3YWbDkMYwmT yfPz2a2XEFq27yshGMQgjXUZgtlwTUgSNI/xiHBz8/LSJ1vk0dgT/tYlTsvQmeKT8uQN Q5Ig== MIME-Version: 1.0 Received: by 10.52.24.142 with SMTP id u14mr1474525vdf.110.1349887080115; Wed, 10 Oct 2012 09:38:00 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.59.5.72 with HTTP; Wed, 10 Oct 2012 09:38:00 -0700 (PDT) In-Reply-To: <5075A20A.204@gmx.de> References: <50758EE7.1070101@gmx.de> <50758FA6.3000708@gmx.de> <50759349.5070001@gmx.de> <1349885059.24581.YahooMailNeo@web31801.mail.mud.yahoo.com> <5075A20A.204@gmx.de> Date: Wed, 10 Oct 2012 12:38:00 -0400 X-Google-Sender-Auth: iPn9nyLt5bZUstTOCZX-Z_LVyUE Message-ID: Subject: Re: Link Relations registrations for OAuth From: Barry Leiba To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Cc: William Mills , "link-relations@ietf.org" X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 16:38:01 -0000 >> Is there an advantage to the AD process or Independent Stream? I'm happy >> to do either, but I'm not familiar with either so I need to know next steps >> please. > > I don't think it matters a lot. I agree. > An AD sponsoring it will probably help process-wise. On the other hand, it > would be nice to demonstrate that we don't *need* an AD here, so it would > also be nice to test the Independent Stream approach. We're already testing it with Herbert van de Sompel's document. The difference is that an Independent Stream document goes directly to the RFC Editor (the Independent Stream Editor (ISE), specifically); see http://www.rfc-editor.org/indsubs.html Those documents can't be Standards Track or BCP, but that doesn't matter here (it'll be Informational either way). The ISE will review it, and wil send it to a couple of other reviewers. It will then go to the IESG for a check that it's not trying to skirt IETF process and doesn't interfere with IETF work (in this case, that's an easy pass, but it takes a couple of weeks in the schedule). The document will be published with boilerplate that does not say that it has the consensus of the IETF community. I don't know how long the ISE is taking to review and approve documents. With an AD-sponsored document, you need to get an AD (I'll do it, once the designated experts have given their approval for the registrations), and then the document goes out for a four-week IETF last call. Then it gets put on an IESG telechat for formal approval, and the IESG can evaluate it and ask for changes. The likely time frame is 5 or 6 weeks from the time the document gets approval from the designated experts to the time it gets IESG approval, though it can be longer if there are a lot of IESG comments. In either case, it then goes to the RFC Editor queue, and IANA can make the registration. I suggest you go for the AD sponsorship path, since you do have a willing AD. When you have the document changes, post back to this list. When the DEs say it's ready for approval, I'll send out the IETF last call. Barry From jan.algermissen@nordsc.com Fri Oct 12 07:22:19 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4F5B21F8496 for ; Fri, 12 Oct 2012 07:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id acNgdTtpfQ+6 for ; Fri, 12 Oct 2012 07:22:19 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8BA21F865E for ; Fri, 12 Oct 2012 07:22:19 -0700 (PDT) Received: from [192.168.2.103] (p548FA255.dip.t-dialin.net [84.143.162.85]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0Lno8B-1TrMAv0KHn-00hNR7; Fri, 12 Oct 2012 16:22:18 +0200 From: Jan Algermissen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: http://tools.ietf.org/html/draft-wilde-profile-link-03 Date: Fri, 12 Oct 2012 16:22:17 +0200 Message-Id: To: link-relations@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:F19ATJ6x8DTqpI0rp+MqGDaXeN8F/YvSuAPLJ30Z1qU gLjkE4Uf76ayteB+eUgbk7stANLSGUJuqnrV/GiMWAHE2NWm6P O4BIirZspyVDZ7AjD3X5Kn3Qh1swBaFxOvo/oT4++ihSUHUrQB lqyhGxhyFzYcl9WKWFEeGVfJrySK1Qz16zXWlm/reQzM4wUWb8 QHi5FVmWkc8rdopHaUKet3RX534LX2+KN0rp1t/fdBh3XQQNb4 WXTeWXCmNnaCeR4xNrrp0f1yz0P/O2l3Ciwv9BuVajHgbTd50Q +qXODnYdGdBzFZCk6vgN4pSYy8UH8kPpMrvQpzNOIxJrFBN9Xf tCfgV4/TkvW+p3kvt+qyiV8vi2DMhC4lWbD7vh09aw300yJK5m fzvkoFwBn1u1w== X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 14:22:20 -0000 Erik, from my POV http://tools.ietf.org/html/draft-wilde-profile-link-03 is fine One thing I saw (but I have not given -03 an in-depth review) "to use referencable URIs and use a representation" s/referencable/dereferencable/ ? Cheers, Jan From algermissen1971@mac.com Fri Oct 12 09:16:20 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F18B621F86DB for ; Fri, 12 Oct 2012 09:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2RHR7CzdF6a for ; Fri, 12 Oct 2012 09:16:19 -0700 (PDT) Received: from nk11p03mm-asmtp008.mac.com (nk11p03mm-asmtpout008.mac.com [17.158.232.43]) by ietfa.amsl.com (Postfix) with ESMTP id 8F97B21F86DA for ; Fri, 12 Oct 2012 09:16:19 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [192.168.2.103] ([84.143.162.85]) by nk11p03mm-asmtp008.mac.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Jan 3 2012)) with ESMTPSA id <0MBS00LODFV43UA0@nk11p03mm-asmtp008.mac.com> for link-relations@ietf.org; Fri, 12 Oct 2012 16:16:18 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855,1.0.431,0.0.0000 definitions=2012-10-12_05:2012-10-12, 2012-10-12, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1210120157 From: Jan Algermissen Subject: http://tools.ietf.org/html/draft-wilde-describes-link-01 Date: Fri, 12 Oct 2012 18:16:15 +0200 Message-id: <01137153-830B-487C-A465-21C38E03CB9E@mac.com> To: link-relations@ietf.org X-Mailer: Apple Mail (2.1283) X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 16:16:20 -0000 Erik, I think http://tools.ietf.org/html/draft-wilde-describes-link-01 sufficiently defines 'describes' and is good to go. (I must say I had a hard time parsing some of the sentences :o) I don't think the matter at hand justifies the effort of further polishing - but if you find spare time you might probably want to give it another read ;-) Jan Out of curiosity: is there a special reason you go into such detail regarding the issue that the relation does not indicate or constrain representation types? From jan.algermissen@nordsc.com Fri Oct 12 09:40:25 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87AA421F8743 for ; Fri, 12 Oct 2012 09:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGeTDMWkTasu for ; Fri, 12 Oct 2012 09:40:25 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by ietfa.amsl.com (Postfix) with ESMTP id C95B521F872E for ; Fri, 12 Oct 2012 09:40:24 -0700 (PDT) Received: from [192.168.2.103] (p548FA255.dip.t-dialin.net [84.143.162.85]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0MYeLS-1SsRfx3k7W-00VNFM; Fri, 12 Oct 2012 18:40:23 +0200 From: Jan Algermissen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: http://tools.ietf.org/html/draft-snell-additional-link-relations-05 Date: Fri, 12 Oct 2012 18:40:22 +0200 Message-Id: To: link-relations@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:4sc0X6vME0vS1XE7k9ha1L/fJcQ+lHDkywKf4f3wr94 Ryky2wbp/cKALse0OZ4t4niLW0De0KInt2Yl85q+8KOGnTNdP9 +msnTcjAclPR00bevpDqQiNHYXV1scSR9i0IVRG2ebgKtLo5+A vdVZEH8jb9VQY4QP2pudvQRVV2GxJkXnxqo6YEM4EowmySu4fh eddKuvbD1ZaYwGsnY8+1FicAjJgqnsEBZQcvBSo0tyxuJmPWDE tZ2QJHSArfbj2fdXxfxQZxDOG4SEAx5ysPtH3fv0shJBNlzy7i Iv7tvkq9CAzlUcvzwJ2/8JNQYJpFcakIIIYzkaN/Pid6V83FkD JHqIl8YzUZ1oSzKY2+U1Z37yGze7nIUplcrgYheFt+jBHeVU03 DqtWfYxWRsGYA== X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 16:40:25 -0000 Hi James, some remarks on = http://tools.ietf.org/html/draft-snell-additional-link-relations-05 Having said that - I think the draft is fine. 2. "about" Does it make sense to explain any intended and/or not intended = similarity to rdf:about? Can an RDF processor infer something when seeing links of this rel? 3. "preview" Although I have an understanding of what a 'preview' is, it might be = helpful to explain further in the text what it means for one resource to be the preview of another. = There seems to me to be quite some implied semantics that could be useful to exaplaint. When I, as a client, learn that B is preview of A, what does that imply = to me? - can I publish B to replace A? - should I use B for editing because it contains the current 'latest' = version of A? - ...=20 Ignoring that, what is the value of knowing that B is a preview of A? Can you provide a use case? (I indeed found 'preview' very clear at = first but then it got me thinking what that would mean to me, as a client) 6. "type" That has been said already: s/type=3D"type"/rel=3D"type"/ Is this equivalent to rdf:type? Does it make sense to note that? See = above. Jan= From jan.algermissen@nordsc.com Tue Oct 16 01:33:22 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E61B121F8887 for ; Tue, 16 Oct 2012 01:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkNxrfKOzptC for ; Tue, 16 Oct 2012 01:33:22 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3169B21F8873 for ; Tue, 16 Oct 2012 01:33:22 -0700 (PDT) Received: from [10.90.131.204] ([87.253.171.193]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0Lvdma-1TPMKK3ysG-017XJX; Tue, 16 Oct 2012 10:33:21 +0200 From: Jan Algermissen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: edit-form and create-form link relations Date: Tue, 16 Oct 2012 10:33:23 +0200 Message-Id: <3832C34E-7ED1-422A-ACD9-388D3281C42D@nordsc.com> To: link-relations@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:8sbS8bjqLZAXtX2EtNipNmmUXYeSvinGB6Pu56cHoA+ hoyuKpLCYnT9kkG8QTDHHyR3PLjs+UL82dOc9cLTyB21ngfJbD CQcSglWpGe0ECjckMXtxqSWATD0l/DnQ9R16QY1P4vgyKFGfIt Bj4eCZGvebH/+XIo8ITiivSCZ7cuAJKPrE646MeCWYR63Ie4nr dpqCw9MVl5c/hK5tS8NqykswdGraD+1oLwlG2owLamelBpKlB6 a6tYyxJ8qAyWmOHh86zwKGlGK8tpkiGXsw/cuiQMCk8JwRQSvj 4lDik4ajWRx+1nOdduColwgBY0Gmc1PtmOC2uIU4gTRFzoTtzr 4dIMzbq6DOFfJo6fksSQKQN2dspUhFnVx+IyXUNc9pC3UBMnsL HKDFR2ASEtTmA== X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 08:33:23 -0000 Ioseb, as discussed yesterday, here are a few final remarks on your draft. =46rom my POV the link relations are ready to be published then. Can you = update and request formal registration? Review of = http://www.ietf.org/id/draft-ioseb-dzmanashvili-link-relation-07.txt 3.1 The "create-form" Link Relation=20 - add 'Type' =3D> The "create-form" Link Relation Type - Suggested minor rewording When included in a response, the "create-form" link relation indicates = a target resource that represents a form that can be used to append a new member to the = link context. 3.1.1 - Suggested rewording If the form representation includes a submission URI this URI MUST be = used to submit the form. The context URI SHOULD be used otherwise. If the form representation includes a submission method this method = MUST be used for submit requests. HTTP's POST method SHOULD be used otherwise. 3.2 The "edit-form" Link Relation - add 'Type' =3D> The "edit-form" Link Relation Type - Suggested minor rewording =20 When included in a response, the "edit-form" link relation indicates a target resource that represents a form that can be used for updating the context resource. 3.2.1 - Suggested rewording If the form representation includes a submission URI this URI MUST be = used to submit the form. The context URI SHOULD be used otherwise. If the form representation includes a submission method this method = MUST be used for submit requests. HTTP's PUT method SHOULD be used otherwise. Jan From ioseb.dzmanashvili@gmail.com Tue Oct 16 11:36:48 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1399121F8A07 for ; Tue, 16 Oct 2012 11:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQLYhtHE4Y-h for ; Tue, 16 Oct 2012 11:36:40 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id B75F521F89E1 for ; Tue, 16 Oct 2012 11:36:38 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so3833642wgb.13 for ; Tue, 16 Oct 2012 11:36:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type; bh=qBk9+Pn2CvwPPVxh4po5pXt7nhgtZst4UHvrMyioCLY=; b=EIrmBnGmmV+81tl/l0rZTvyRUK+8wBGaNbvw1Itc0EmKp8YFw4Tz6h4OHZ7nWLwHpP c/l91ATPO0te9PTEKh753/I27D1MLcGYQ4AmwWdDwGATKa5egsNSr6GaZe5htlWbhKez CPLhlG/mJ3IXTjXqhjynHRTfh4doC3YWPDPYL5fFeDIJp3nyzsBY9tSoGITs6cvApqfP LPnpd50dBjVZQAbAy0nkpvivLbO4Tfx0ojVVSzQO1MXIf0ysgEAdnJ27QOL/5pNkfR51 dd9usfDX1eYT3LSRuNES9H/t/RE14EgVBCg1xuePAxbN5e/M5R1rbPjLbxCC/aEARLXC 7tLw== Received: by 10.216.141.16 with SMTP id f16mr10635106wej.130.1350412597813; Tue, 16 Oct 2012 11:36:37 -0700 (PDT) Received: from [192.168.1.8] ([176.73.174.236]) by mx.google.com with ESMTPS id fp6sm298668wib.0.2012.10.16.11.36.35 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 16 Oct 2012 11:36:36 -0700 (PDT) Date: Tue, 16 Oct 2012 22:36:43 +0400 From: Ioseb Dzmanashvili To: link-relations@ietf.org Message-ID: <941AB4A796644C509E79764136F755A3@gmail.com> In-Reply-To: <795725D9-0667-4995-BDAB-5FD49BF2A670@nordsc.com> References: <3832C34E-7ED1-422A-ACD9-388D3281C42D@nordsc.com> <795725D9-0667-4995-BDAB-5FD49BF2A670@nordsc.com> Subject: Re: edit-form and create-form link relations X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="507da93b_2a6de806_1b2" X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 18:36:48 -0000 --507da93b_2a6de806_1b2 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Jan, I applied all suggested changes and published new version: http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-08 Please let me know if any other changes are required. Best regards, ioseb On Tuesday, October 16, 2012 at 10:02 PM, Jan Algermissen wrote: > Did that earlier today: > > Jan > > > > Begin forwarded message: > > > From: Jan Algermissen > > Subject: edit-form and create-form link relations > > Date: October 16, 2012 10:33:23 AM GMT+02:00 > > To: link-relations@ietf.org (mailto:link-relations@ietf.org) > > > > Ioseb, > > > > as discussed yesterday, here are a few final remarks on your draft. > > > > From my POV the link relations are ready to be published then. Can you update and request formal registration? > > > > > > Review of http://www.ietf.org/id/draft-ioseb-dzmanashvili-link-relation-07.txt > > > > 3.1 The "create-form" Link Relation > > > > - add 'Type' => The "create-form" Link Relation Type > > > > - Suggested minor rewording > > > > When included in a response, the "create-form" link relation indicates a target resource > > that represents a form that can be used to append a new member to the link context. > > > > 3.1.1 > > > > - Suggested rewording > > > > If the form representation includes a submission URI this URI MUST be used > > to submit the form. The context URI SHOULD be used otherwise. > > > > If the form representation includes a submission method this method MUST be > > used for submit requests. HTTP's POST method SHOULD be used otherwise. > > > > > > 3.2 The "edit-form" Link Relation > > > > - add 'Type' => The "edit-form" Link Relation Type > > > > - Suggested minor rewording > > > > When included in a response, the "edit-form" link relation indicates > > a target resource that represents a form that can be used for updating > > the context resource. > > > > 3.2.1 > > > > - Suggested rewording > > > > If the form representation includes a submission URI this URI MUST be used > > to submit the form. The context URI SHOULD be used otherwise. > > > > If the form representation includes a submission method this method MUST be > > used for submit requests. HTTP's PUT method SHOULD be used otherwise. > > > > > > > > > > Jan --507da93b_2a6de806_1b2 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Jan, 

I applied all= suggested changes and published new version: http://too= ls.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-08
=
Please let me know if any other changes are required.

Best regards,
ioseb
=20

On Tuesday, October 16= , 2012 at 10:02 PM, Jan Algermissen wrote:

Did that earlier today:

Jan



Begin forwarded message:

=46rom: Jan Algermissen <jan.algermissen=40nordsc.com>
Subj= ect: edit-form and create-form link relations
Date: October 16,= 2012 10:33:23 AM GMT+02:00

= Ioseb,

as discussed yesterday, here are a few fi= nal remarks on your draft.

=46rom my POV the lin= k relations are ready to be published then. Can you update and request fo= rmal registration=3F


Review of http://www.ietf.org/id/draft-ioseb-dzmanashvili-link-relation-0= 7.txt

3.1 The =22create-form=22 Link Relatio= n

- add 'Type' =3D> The =22create-form=22 Li= nk Relation Type

- Suggested minor rewording

When included in a response, the =22create-form=22= link relation indicates a target resource
that represents a f= orm that can be used to append a new member to the link context.

3.1.1

- Suggested rewording

If the form representation includes a submission U= RI this URI MUST be used
to submit the form. The context URI S= HOULD be used otherwise.

If the form representa= tion includes a submission method this method MUST be
used for= submit requests. HTTP's POST method SHOULD be used otherwise.
=

3.2 The =22edit-form=22 Link Relation
=

- add 'Type' =3D> The =22edit-form=22 Link Relati= on Type

- Suggested minor rewording
When included in a response, the =22edit-form=22 link relat= ion indicates
a target resource that represents a form that ca= n be used for updating
the context resource.

3.2.1

- Suggested rewording
If the form representation includes a submission URI this U= RI MUST be used
to submit the form. The context URI SHOULD be = used otherwise.

If the form representation incl= udes a submission method this method MUST be
used for submit r= equests. HTTP's PUT method SHOULD be used otherwise.

=



Jan
=20 =20 =20 =20
=20

--507da93b_2a6de806_1b2-- From jan.algermissen@nordsc.com Tue Oct 16 11:42:25 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3C2F21F8A15 for ; Tue, 16 Oct 2012 11:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.143 X-Spam-Level: X-Spam-Status: No, score=-3.143 tagged_above=-999 required=5 tests=[AWL=-0.894, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CcTrYV9Fodq4 for ; Tue, 16 Oct 2012 11:42:25 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by ietfa.amsl.com (Postfix) with ESMTP id 8645C21F8A0B for ; Tue, 16 Oct 2012 11:42:24 -0700 (PDT) Received: from [192.168.2.103] (p548FB959.dip.t-dialin.net [84.143.185.89]) by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis) id 0LdmTL-1Toh5h3cLD-00iXNh; Tue, 16 Oct 2012 20:42:22 +0200 From: Jan Algermissen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: 'edit-form' and 'create-form' link relations Date: Tue, 16 Oct 2012 20:42:25 +0200 Message-Id: <477A6BC0-58E6-4640-9CB6-E0FBAB66B493@nordsc.com> To: link-relations@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:o8cZszf/9WT0VRauUwPEPGhOobsZKavipzVPAvJmdoW 8XWxpA7RbqoYdGfqlxLz3SUjKyGtHTRqj5d2idBzJWG+i2mWUb vxNAOWxyE27+uF/DlW+fzQ+e5sRD3Fh8oNfPUrzg/CgdDuJMK7 wRLU6O6/C4vZjpn+0u9Q9TirdaubNGWBLkrMP0dlEPIlyO20xu HFsyucLudS5fhGllFVFEyTCj9+m8haS85ntYkBcCTj8TK4LuHB E+jNlmOQ0oCszeaPw4hzYrSvwTdNM0Q9kneQPZV3CJ4IEuGqx1 B0nOLpU0QDfAAxV11++7S1TRd8NC1tMP6ngvMF2F2y/2ha71C7 MCxKRTdXzmkZG6alWaOsD7xjPPcfZjcjnvkmY+xIru3WqMHZwY GHtsazL+KRS1Q== Cc: Ioseb Dzmanashvili X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 18:42:25 -0000 Hi, http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-08 I think the latest version of the draft is ready to go. I approve the = specified link relations. @Julian, @Mark: I am still lost process wise. What's next? Jan= From ioseb.dzmanashvili@gmail.com Tue Oct 16 11:44:19 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 269DB21F8976 for ; Tue, 16 Oct 2012 11:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3SaJQtMjbIf for ; Tue, 16 Oct 2012 11:44:18 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 25A6321F896B for ; Tue, 16 Oct 2012 11:44:16 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so4366387wey.31 for ; Tue, 16 Oct 2012 11:44:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type; bh=qFwcNAh8hN7Oyzaqwyv6qPb1LSEnHUSKSzvRnPgwTUs=; b=qHJtInw5Ck/Bfr2TQZv6JvArso2GjdsP0hCaONTBKImD4nFqDBxPCDMKvZoRmigrJg CZVJj0f7x66E7IAJ18M1mgad7PC+uHITwYgv6tCsQrUA0XTZuJY0XiIrXzSJ3Am0oBOv sJZNrZHH191p0t49+QldOC9iuAr+wu8ogmHR5ARNF/oqa6qEXW8u+Hv1iVc0euB3aC0z m/qfzlAnHOuDqVo9eCh8YCQQ17E6dtvb/hGRd0s82wRZIWKsTjQZ2d8JW+BEPyG356/E zUmHnQBTjV6Ret8wfpRCXN14dovyK8ruUiHwgCTjzECITvMDwSvNGNpNGI8rW5ynFFFF hQsw== Received: by 10.216.210.11 with SMTP id t11mr9839383weo.92.1350413056071; Tue, 16 Oct 2012 11:44:16 -0700 (PDT) Received: from [192.168.1.8] ([176.73.174.236]) by mx.google.com with ESMTPS id gm7sm23166004wib.10.2012.10.16.11.44.13 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 16 Oct 2012 11:44:15 -0700 (PDT) Date: Tue, 16 Oct 2012 22:44:22 +0400 From: Ioseb Dzmanashvili To: Jan Algermissen Message-ID: <994AB331364F45E48944E40CC8E05085@gmail.com> In-Reply-To: <477A6BC0-58E6-4640-9CB6-E0FBAB66B493@nordsc.com> References: <477A6BC0-58E6-4640-9CB6-E0FBAB66B493@nordsc.com> Subject: Re: 'edit-form' and 'create-form' link relations X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="507dab06_7ab49daf_1b2" Cc: link-relations@ietf.org X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 18:44:19 -0000 --507dab06_7ab49daf_1b2 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Thanks! ioseb On Tuesday, October 16, 2012 at 10:42 PM, Jan Algermissen wrote: > Hi, > > http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-08 > > I think the latest version of the draft is ready to go. I approve the specified link relations. > > @Julian, @Mark: I am still lost process wise. What's next? > > Jan --507dab06_7ab49daf_1b2 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Thanks=21 

ioseb
= =20

On Tuesday, October 16= , 2012 at 10:42 PM, Jan Algermissen wrote:

Hi,


I think the latest version of the draft= is ready to go. I approve the specified link relations.

=40Julian, =40Mark: I am still lost process wise. What's next=3F=

Jan
=20 =20 =20 =20
=20

--507dab06_7ab49daf_1b2-- From julian.reschke@gmx.de Tue Oct 16 12:14:38 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 930FC21F8899 for ; Tue, 16 Oct 2012 12:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jzZ71jXaodC for ; Tue, 16 Oct 2012 12:14:38 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 9AFBF21F888F for ; Tue, 16 Oct 2012 12:14:37 -0700 (PDT) Received: (qmail invoked by alias); 16 Oct 2012 19:13:51 -0000 Received: from unknown (EHLO [172.24.22.96]) [173.226.97.253] by mail.gmx.net (mp071) with SMTP; 16 Oct 2012 21:13:51 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19BxF552nlBQNrbqO8z+ttoJ2WvwleTz1mFig7+f5 eo+piAPjvLn/WG Message-ID: <507DB1EC.6020301@gmx.de> Date: Tue, 16 Oct 2012 21:13:48 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Jan Algermissen Subject: Re: 'edit-form' and 'create-form' link relations References: <477A6BC0-58E6-4640-9CB6-E0FBAB66B493@nordsc.com> In-Reply-To: <477A6BC0-58E6-4640-9CB6-E0FBAB66B493@nordsc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Ioseb Dzmanashvili , link-relations@ietf.org X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 19:14:38 -0000 On 2012-10-16 20:42, Jan Algermissen wrote: > Hi, > > http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-08 > > I think the latest version of the draft is ready to go. I approve the specified link relations. > > @Julian, @Mark: I am still lost process wise. What's next? > > Jan > ... The Internet Draft needs to be published as RFC. has some instructions for publishing in the IETF stream. Alternatively, one can try an individual submission to the RFC Editor, see . Best regards, Julian From ioseb.dzmanashvili@gmail.com Tue Oct 16 12:59:34 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD8021F887F for ; Tue, 16 Oct 2012 12:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0w5Sd1M2S1U5 for ; Tue, 16 Oct 2012 12:59:34 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9D23B21F87D7 for ; Tue, 16 Oct 2012 12:59:33 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so3876095wgb.13 for ; Tue, 16 Oct 2012 12:59:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type; bh=Y3sM64wmXkqWz5QyapifhuRewrP8EMYLqaTs25uIIms=; b=VUN7I5XGnOyfjI7Mslxz8MzqJ7bOqVpi/zfsgYNNyVEWr7zRmCX9D/3KwesMBoQRJi tjQkBOiGoMjFCN0oQfQdTjQ3yFmI1Vw5dtUr0qIelHw0SNaD8Lx8wJFcAzjBjF7VU3fK 3BWnmKDmUyc9fWQIJWGStK011iLXsg7O2VbETR86NwIinugC0wHlZJS2NrAhPt4QZsHf J3tZK8W+LNl98zP1PywtQ+jKrO+OpYrKmvueeMlNSjRjs+iIJrCIG7eyg7nWSAcjZtpo kM3cGIAOqoVLJuJ6zl3n4WJj1qG0yIf2ijWPA/Xh9j9bLXmIn2YUnnjvRzTdS4I9XOWG h89g== Received: by 10.216.193.65 with SMTP id j43mr9295487wen.141.1350417572688; Tue, 16 Oct 2012 12:59:32 -0700 (PDT) Received: from [192.168.1.8] ([176.73.174.236]) by mx.google.com with ESMTPS id cu1sm20648732wib.6.2012.10.16.12.59.29 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 16 Oct 2012 12:59:30 -0700 (PDT) Date: Tue, 16 Oct 2012 23:59:37 +0400 From: Ioseb Dzmanashvili To: Julian Reschke Message-ID: <8CD3B9BB6C754247979F2F41A532B78A@gmail.com> In-Reply-To: <507DB1EC.6020301@gmx.de> References: <477A6BC0-58E6-4640-9CB6-E0FBAB66B493@nordsc.com> <507DB1EC.6020301@gmx.de> Subject: Re: 'edit-form' and 'create-form' link relations X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="507dbca9_1f461b51_1b2" Cc: link-relations@ietf.org X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 19:59:34 -0000 --507dbca9_1f461b51_1b2 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Julian, Thank you very much! @Jan I sent email to rfc-ise@rfc-editor.org with all necessary details listed on this page https://www.rfc-editor.org/indsubs.html. Best regards, ioseb On Tuesday, October 16, 2012 at 11:13 PM, Julian Reschke wrote: > On 2012-10-16 20:42, Jan Algermissen wrote: > > Hi, > > > > http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-08 > > > > I think the latest version of the draft is ready to go. I approve the specified link relations. > > > > @Julian, @Mark: I am still lost process wise. What's next? > > > > Jan > > ... > > > > > The Internet Draft needs to be published as RFC. > has some instructions for > publishing in the IETF stream. > > Alternatively, one can try an individual submission to the RFC Editor, > see . > > Best regards, Julian --507dbca9_1f461b51_1b2 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Julian,

Thank you very m= uch=21

=40Jan

I sent em= ail to rfc-ise=40rfc-editor.org with all necessary details listed on this= page https:= //www.rfc-editor.org/indsubs.html.

Best rega= rds,
ioseb
=20

On Tuesday, October 16= , 2012 at 11:13 PM, Julian Reschke wrote:

On 2012-10-16 20:42, Jan Algermi= ssen wrote:
Hi,

I think the latest vers= ion of the draft is ready to go. I approve the specified link relations.<= /div>

=40Julian, =40Mark: I am still lost process wise= . What's next=3F

Jan
...

The Internet Draft needs to be published a= s R=46C.
<http://www.ietf.org/tao.html=23rfc.section.6.1> has = some instructions for
publishing in the IET=46 stream.

Alternatively, one can try an individual submission to = the R=46C Editor,
see <https://www.rfc-editor.org/indsubs.html>.

Best regards, Julian
=20 =20 =20 =20
=20

--507dbca9_1f461b51_1b2-- From jasnell@gmail.com Tue Oct 16 17:01:57 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFF1D1F0CB4 for ; Tue, 16 Oct 2012 17:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[AWL=-1.103, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7EjSEs-e8PG for ; Tue, 16 Oct 2012 17:01:57 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id B8E5B1F0423 for ; Tue, 16 Oct 2012 17:01:56 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id s14so6332778qcg.31 for ; Tue, 16 Oct 2012 17:01:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=YdIIG0tPuFs+YlNG0yU5H/qMb/2kauDVXWJiXi65P8A=; b=IquhSvtz9FQBIGmRoNj2LLTomLOWkvkwwrUbT5zzNGSfJW5KWhkEwviR8fgbKHk5Ok 1pebnjiQCWHRvNDV1U/sIWR7/GGb4uabYD5TD3R3mQ+o+0RIRRNfBsr5cksE8ryhzMDn J7ceUj8yGM6so7QFSosfL54L/R8NRfGafhRseSNtWEVVGubXLN95HjDpcIyQxEukEq2x 0ABWgCGTGxx8Vwufwt6FzAbEULvLQLgcaNqBcIG2pVo6kRFgt9otU3KujhXKnZ6eXrtX RJPDzO42K1uie1f+GiQn7jKFq0+iQ8wIHTnjbnLHc1rRgoDy1l/l/YcgbsCX53bXHrHh UiVA== Received: by 10.49.63.104 with SMTP id f8mr39836413qes.29.1350432116284; Tue, 16 Oct 2012 17:01:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.81.230 with HTTP; Tue, 16 Oct 2012 17:01:36 -0700 (PDT) In-Reply-To: <477A6BC0-58E6-4640-9CB6-E0FBAB66B493@nordsc.com> References: <477A6BC0-58E6-4640-9CB6-E0FBAB66B493@nordsc.com> From: James M Snell Date: Tue, 16 Oct 2012 17:01:36 -0700 Message-ID: Subject: Re: 'edit-form' and 'create-form' link relations To: Jan Algermissen Content-Type: multipart/alternative; boundary=047d7bdc1a3a959d9504cc35fa4f Cc: Ioseb Dzmanashvili , link-relations@ietf.org X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 00:01:57 -0000 --047d7bdc1a3a959d9504cc35fa4f Content-Type: text/plain; charset=UTF-8 Just some quick feedback based on an initial read of the specification... Note: I have not had direct implementation experience with this particular mechanism so please take this feedback for what it's worth... Several points: 1. In general these seem useful, but I'm concerned that they may make some unspecified assumptions... seemingly assuming that an html form is always on the other side of the link without actually coming out and saying so. 2. create-form seems too specific to me at first review. Why not simply "create" and allow the media type of the referenced resource specify exactly what kind of thing it is. For example: Link: ; rel="create"; type="application/atom+xml" Could potentially be used to tell me where to post new items to an Atompub collection. Link: ; rel="create"; type="text/html" Essentially tells me that there's an HTML page presumably with instructions or a form for editing. If you went with this approach, the existing "edit" link relation could similarly be used in place of "edit-form". Note that the definition of the existing "edit" link relation is that it "refers to a resource that can be used to edit the link's context"... seems like a pretty good fit to me. Link: ; rel="edit"; type="text/html" 3. I don't believe the requirements in sections 3.1.1 and 3.2.1 are necessary at all. Nor is the error handling bit in section 3.3. - James On Tue, Oct 16, 2012 at 11:42 AM, Jan Algermissen < jan.algermissen@nordsc.com> wrote: > Hi, > > http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-08 > > I think the latest version of the draft is ready to go. I approve the > specified link relations. > > @Julian, @Mark: I am still lost process wise. What's next? > > Jan > _______________________________________________ > link-relations mailing list > link-relations@ietf.org > https://www.ietf.org/mailman/listinfo/link-relations > --047d7bdc1a3a959d9504cc35fa4f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Just some quick feedback based on an i= nitial read of the specification... Note: I have not had direct implementat= ion experience with this particular mechanism so please take this feedback = for what it's worth...

Several points:=

1. In general these seem useful, but I= 9;m concerned that they may make some unspecified assumptions... seemingly = assuming that an html form is always on the other side of the link without = actually coming out and saying so.

2. create-form seems too specific to me at firs= t review. Why not simply "create" and allow the media type of the= referenced resource specify exactly what kind of thing it is.=C2=A0=

For example: =C2=A0

=C2=A0 Link: <http://example.org/atompub/collection>; rel=3D"create"= ;; type=3D"application/atom+xml"

Could potentially be used to tell me where to p= ost new items to an Atompub collection.

=C2=A0 Link: <http://example.org/html/foo.html= >; rel=3D"create"; type=3D"text/html"

Essentially tells m= e that there's an HTML page presumably with instructions or a form for = editing.

=
If you went with this approach, = the existing "edit" link relation could similarly be used in plac= e of "edit-form". Note that the definition of the existing "= edit" link relation is that it "refers to a resource that can be = used to edit the link's context"... seems like a pretty good fit t= o me.

=C2=A0 Link: <http://example.org/html/edit.html>; rel=3D"edit= "; type=3D"text/html"

3. I don't believe the requirements in sect= ions 3.1.1 and 3.2.1 are necessary at all. Nor is the error handling bit in= section 3.3.

- James


On Tue= , Oct 16, 2012 at 11:42 AM, Jan Algermissen <jan.algermissen@no= rdsc.com> wrote:
Hi,

http://tools.ietf.org/html/draft-ioseb-dzmanashvili= -link-relation-08

I think the latest version of the draft is ready to go. I approve the speci= fied link relations.

@Julian, @Mark: I am still lost process wise. What's next?

Jan
_______________________________________________
link-relations mailing list
link-relations@ietf.org
https://www.ietf.org/mailman/listinfo/link-relations

--047d7bdc1a3a959d9504cc35fa4f-- From jan.algermissen@nordsc.com Tue Oct 16 23:13:54 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 198D821F85F7 for ; Tue, 16 Oct 2012 23:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHjtZSwgYrFO for ; Tue, 16 Oct 2012 23:13:53 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id 20AC321F8593 for ; Tue, 16 Oct 2012 23:13:53 -0700 (PDT) Received: from [10.84.174.216] (tmo-103-55.customers.d1-online.com [80.187.103.55]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0MNRWv-1TI3M61pQ9-006sQ1; Wed, 17 Oct 2012 08:13:51 +0200 Subject: Re: 'edit-form' and 'create-form' link relations Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Jan Algermissen In-Reply-To: Date: Wed, 17 Oct 2012 08:13:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0BEC80EE-F3AD-4898-85D5-595FE1472C4D@nordsc.com> References: <477A6BC0-58E6-4640-9CB6-E0FBAB66B493@nordsc.com> To: James M Snell X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:RpYsZC6vLVJ+oXOgc3iiA78wnjXYa5WG5b8Kl18/x0x hSgMAZDEKlpG42dQbGWDYrts8KYTHF+rDDmBKC+oYjraeqASfX GIXqZTiPyzljqdiY1MRFRlEVrWFVtpm6oLH0hxidZfaH4GELuF YTCY+5rgiN9RiYlkE5WH6EQTCXTZvRjbJMWxPs5PydcUSsA+2m ITwh9kr2Wxi2Wjtwh82mo9WrPtQS4uJGbS4jgpwJvLb+z0/M4F J1A8TLv81CedTqFp2/d74LmC9R08hTzX+J8xmzsdrXVb4W777U uXXwILw43utOABYMX5NKIB/+jGKuD7n2qtRp7RGL5IKBpIK1Lo SXJ6gP0JYvzwKMPr4EXpL228AsYeZ66sbFSh1jJO6eoZGMUP6j TdHNxTurgzV5Q== Cc: Ioseb Dzmanashvili , link-relations@ietf.org X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 06:13:54 -0000 Hi James, On Oct 17, 2012, at 2:01 AM, James M Snell wrote: > Just some quick feedback based on an initial read of the = specification... Note: I have not had direct implementation experience I do since yesterday :-) Suddenly popped up. > with this particular mechanism so please take this feedback for what = it's worth... >=20 > Several points: >=20 > 1. In general these seem useful, but I'm concerned that they may make = some unspecified assumptions... seemingly assuming that an html form is = always on the other side of the link without actually coming out and = saying so. I never saw it that way. Why do you think there is an HTML-form = assumption? >=20 > 2. create-form seems too specific to me at first review. Why not = simply "create" and allow the media type of the referenced resource = specify exactly what kind of thing it is.=20 >=20 > For example: =20 >=20 > Link: ; rel=3D"create"; = type=3D"application/atom+xml" >=20 > Could potentially be used to tell me where to post new items to an = Atompub collection. >=20 > Link: ; rel=3D"create"; = type=3D"text/html" Hmm, I think you are misreading the rels. They are only for finding the = form that tells me how to construct what I send to the creation (or = update) URI which I know already. >=20 > Essentially tells me that there's an HTML page presumably with = instructions or a form for editing. The question of the form format would be negotiated during the GET form = request/response roundtrip. The form could be available in many = representations, actually. >=20 > If you went with this approach, the existing "edit" link relation = could similarly be used in place of "edit-form". Note that the = definition of the existing "edit" link relation is that it "refers to a = resource that can be used to edit the link's context"... seems like a = pretty good fit to me. IIRC 'edit' has more the semantic of 'this is the primary URI of a = resource where you should turn to to make changes. I agree that you = could read atom that way, but seems like unclear wording to me. >=20 > Link: ; rel=3D"edit"; = type=3D"text/html" >=20 > 3. I don't believe the requirements in sections 3.1.1 and 3.2.1 are = necessary at all. Nor is the error handling bit in section Yeah, was thinking the same. OTH, I found it interesting that Ioseb = thought of them and I had discussions yesterday that are directly = answered by these sections. Thanks for taking a look. Jan > 3.3. >=20 > - James >=20 >=20 > On Tue, Oct 16, 2012 at 11:42 AM, Jan Algermissen = wrote: > Hi, >=20 > http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-08 >=20 > I think the latest version of the draft is ready to go. I approve the = specified link relations. >=20 > @Julian, @Mark: I am still lost process wise. What's next? >=20 > Jan > _______________________________________________ > link-relations mailing list > link-relations@ietf.org > https://www.ietf.org/mailman/listinfo/link-relations >=20 From ioseb.dzmanashvili@gmail.com Tue Oct 16 23:24:08 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B11321F86C1 for ; Tue, 16 Oct 2012 23:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6CH1xw+BNE-l for ; Tue, 16 Oct 2012 23:24:07 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0E7F021F86BA for ; Tue, 16 Oct 2012 23:24:06 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so4100096wgb.13 for ; Tue, 16 Oct 2012 23:24:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type; bh=J+oslC8jajqjDSSRiGCYA16JNbsuYFTB2FUgRjKLpYw=; b=DWwNhkeL1lFoAvI/7BP+SbqUagwdbuZuGAPaLMPn4HU3m5sbefRrku+V4sHZzdixJ9 u6JxOrak2yrYe9ZsyvUuug8b4BmhYi9ROLujgXKX9vYVgcc3GDWazOjWaEHCbpiPa+ur Y+rH7ANubMoJiNJTrDbEWohXVCsWhq+wCc42pvNzSTbE015K6MVD9MddeZEB8/tqLKmD fB9qjvoThtr4kq0rj/IYfRFGk6YntvHv/DB3n0ZDkCN59fPuaCqEeRfj41/CqFu4aIsc 7VJPqUjKUkj3U3oK38yFmCjUGdgWR4vF+s1xzFsmedNog7bcXkx8btSbh8zsqoZvwXzY qaZg== Received: by 10.216.212.66 with SMTP id x44mr9964693weo.123.1350455046058; Tue, 16 Oct 2012 23:24:06 -0700 (PDT) Received: from [10.131.33.116] ([213.131.60.234]) by mx.google.com with ESMTPS id b7sm22757564wiz.3.2012.10.16.23.24.04 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 16 Oct 2012 23:24:05 -0700 (PDT) Date: Wed, 17 Oct 2012 10:24:03 +0400 From: Ioseb Dzmanashvili To: Jan Algermissen Message-ID: In-Reply-To: <0BEC80EE-F3AD-4898-85D5-595FE1472C4D@nordsc.com> References: <477A6BC0-58E6-4640-9CB6-E0FBAB66B493@nordsc.com> <0BEC80EE-F3AD-4898-85D5-595FE1472C4D@nordsc.com> Subject: Re: 'edit-form' and 'create-form' link relations X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="507e4f03_3ca88ecf_1b2" Cc: link-relations@ietf.org X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 06:24:08 -0000 --507e4f03_3ca88ecf_1b2 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi James, Thanks for feedback, i can't add anything to Jan's comments. Similar issues were discussed in the past on this mailing list and i think all of them were clarified and spec was adjusted several times accordingly. Best regards, ioseb On Wednesday, October 17, 2012 at 10:13 AM, Jan Algermissen wrote: > Hi James, > > On Oct 17, 2012, at 2:01 AM, James M Snell wrote: > > > Just some quick feedback based on an initial read of the specification... Note: I have not had direct implementation experience > > I do since yesterday :-) Suddenly popped up. > > > with this particular mechanism so please take this feedback for what it's worth... > > > > Several points: > > > > 1. In general these seem useful, but I'm concerned that they may make some unspecified assumptions... seemingly assuming that an html form is always on the other side of the link without actually coming out and saying so. > > I never saw it that way. Why do you think there is an HTML-form assumption? > > > > > 2. create-form seems too specific to me at first review. Why not simply "create" and allow the media type of the referenced resource specify exactly what kind of thing it is. > > > > For example: > > > > Link: ; rel="create"; type="application/atom+xml" > > > > Could potentially be used to tell me where to post new items to an Atompub collection. > > > > Link: ; rel="create"; type="text/html" > > Hmm, I think you are misreading the rels. They are only for finding the form that tells me how to construct what I send to the creation (or update) URI which I know already. > > > > > Essentially tells me that there's an HTML page presumably with instructions or a form for editing. > > The question of the form format would be negotiated during the GET form request/response roundtrip. The form could be available in many representations, actually. > > > > > > If you went with this approach, the existing "edit" link relation could similarly be used in place of "edit-form". Note that the definition of the existing "edit" link relation is that it "refers to a resource that can be used to edit the link's context"... seems like a pretty good fit to me. > > IIRC 'edit' has more the semantic of 'this is the primary URI of a resource where you should turn to to make changes. I agree that you could read atom that way, but seems like unclear wording to me. > > > > > Link: ; rel="edit"; type="text/html" > > > > 3. I don't believe the requirements in sections 3.1.1 and 3.2.1 are necessary at all. Nor is the error handling bit in section > > Yeah, was thinking the same. OTH, I found it interesting that Ioseb thought of them and I had discussions yesterday that are directly answered by these sections. > > Thanks for taking a look. > > Jan > > > > 3.3. > > > > - James > > > > > > On Tue, Oct 16, 2012 at 11:42 AM, Jan Algermissen wrote: > > Hi, > > > > http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-08 > > > > I think the latest version of the draft is ready to go. I approve the specified link relations. > > > > @Julian, @Mark: I am still lost process wise. What's next? > > > > Jan > > _______________________________________________ > > link-relations mailing list > > link-relations@ietf.org (mailto:link-relations@ietf.org) > > https://www.ietf.org/mailman/listinfo/link-relations > > > > > --507e4f03_3ca88ecf_1b2 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
 Hi James, 

Thank= s for feedback, i can't add anything to Jan's comments. Similar issues we= re discussed in the past on this mailing list and i think all of them wer= e clarified and spec was adjusted several times accordingly. 
<= div>
Best regards,
ioseb
=20

On Wednesday, October = 17, 2012 at 10:13 AM, Jan Algermissen wrote:

Hi James,

On Oct 17, 2012, at 2:01 AM, James M Snell wrote:

=
Just some quick feedback based on an i= nitial read of the specification... Note: I have not had direct implement= ation experience

I do since yesterd= ay :-) Suddenly popped up.

with this particular mechanism so please take this feedback= for what it's worth...

Several points:

1. In general these seem useful, but I'm concerned that = they may make some unspecified assumptions... seemingly assuming that an = html form is always on the other side of the link without actually coming= out and saying so.

I never s= aw it that way. Why do you think there is an HTML-form assumption=3F


2.= create-form seems too specific to me at first review. Why not simply =22= create=22 and allow the media type of the referenced resource specify exa= ctly what kind of thing it is.

=46or example: =

Link: <http://example.org/atompub/collection>; rel=3D=22= create=22; type=3D=22application/atom+xml=22

Cou= ld potentially be used to tell me where to post new items to an Atompub c= ollection.

Link: <http://example.org/html/foo.html>; rel=3D=22= create=22; type=3D=22text/html=22

=
Hmm, I think you are misreading the rels. They are only for finding = the form that tells me how to construct what I send to the creation (or u= pdate) URI which I know already.


Essentially tells me that there's an HTM= L page presumably with instructions or a form for editing.

The question of the form format would be ne= gotiated during the GET form request/response roundtrip. The form could b= e available in many representations, actually.

<= br>

If you we= nt with this approach, the existing =22edit=22 link relation could simila= rly be used in place of =22edit-form=22. Note that the definition of the = existing =22edit=22 link relation is that it =22refers to a resource that= can be used to edit the link's context=22... seems like a pretty good fi= t to me.

IIRC 'edit' has more= the semantic of 'this is the primary URI of a resource where you should = turn to to make changes. I agree that you could read atom that way, but s= eems like unclear wording to me.


Link: <http://example.org/html/edit.html>; rel=3D=22= edit=22; type=3D=22text/html=22

3. I don't belie= ve the requirements in sections 3.1.1 and 3.2.1 are necessary at all. Nor= is the error handling bit in section

Yeah, was thinking the same. OTH, I found it interesting that Io= seb thought of them and I had discussions yesterday that are directly ans= wered by these sections.

Thanks for taking a loo= k.

Jan


3.3.

- James


On Tue, Oct 16, 2012 at 11:42 AM, = Jan Algermissen <j= an.algermissen=40nordsc.com> wrote:
Hi,


I think the latest version = of the draft is ready to go. I approve the specified link relations.

=40Julian, =40Mark: I am still lost process wise. Wh= at's next=3F

Jan
=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
link-relations ma= iling list
=20 =20 =20 =20 =20

--507e4f03_3ca88ecf_1b2-- From jasnell@gmail.com Tue Oct 16 23:48:54 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C937721F851B for ; Tue, 16 Oct 2012 23:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.787 X-Spam-Level: X-Spam-Status: No, score=-4.787 tagged_above=-999 required=5 tests=[AWL=-1.189, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PJyNGRbU0Ln for ; Tue, 16 Oct 2012 23:48:53 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 61B9921F8518 for ; Tue, 16 Oct 2012 23:48:53 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id s14so6556692qcg.31 for ; Tue, 16 Oct 2012 23:48:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=JSjHQCAAs+2m7ct/YUxLjIyd88TIDtNxa+CJBnIN+qs=; b=gg1etVSoAVtQ+kHU0cLys4gLv9OvIWOLjOSqm4tZvzTD0wmqbmofaIxlQ/RWZjL4gG I74bFmYCY3H8lXwUn3EGZ7NdfVBcWghXnLympgRBCbaY9JyjrarV6FXOOpMa/3tuwFpu SnB9H7FpfOVD6u0lA1F3mR3PSB5YEMTqiGOt0jcU0xqhF8kwA6HT1rPRQWQwikId1NcZ SQjJ+z1FUJjmaTaW/kNa47EuDKLNZ57DgoZD/tpekttRAKite1n2OahXyCI3CfAHRIcI XF/MKNaJQIYcP+ePmcUY6+CoGJFy1/as//bnPGVU1Mh4ppglDHvaIt/0YR2Ep4G58Ujt HDXw== Received: by 10.49.103.162 with SMTP id fx2mr41311390qeb.1.1350456532528; Tue, 16 Oct 2012 23:48:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.81.230 with HTTP; Tue, 16 Oct 2012 23:48:31 -0700 (PDT) In-Reply-To: <0BEC80EE-F3AD-4898-85D5-595FE1472C4D@nordsc.com> References: <477A6BC0-58E6-4640-9CB6-E0FBAB66B493@nordsc.com> <0BEC80EE-F3AD-4898-85D5-595FE1472C4D@nordsc.com> From: James M Snell Date: Tue, 16 Oct 2012 23:48:31 -0700 Message-ID: Subject: Re: 'edit-form' and 'create-form' link relations To: Jan Algermissen Content-Type: multipart/alternative; boundary=047d7b2e79c8e7ee7c04cc3ba90b Cc: Ioseb Dzmanashvili , link-relations@ietf.org X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 06:48:54 -0000 --047d7b2e79c8e7ee7c04cc3ba90b Content-Type: text/plain; charset=UTF-8 On Tue, Oct 16, 2012 at 11:13 PM, Jan Algermissen < jan.algermissen@nordsc.com> wrote: > Hi James, > > On Oct 17, 2012, at 2:01 AM, James M Snell wrote: > > > Just some quick feedback based on an initial read of the > specification... Note: I have not had direct implementation experience > > I do since yesterday :-) Suddenly popped up. > > > with this particular mechanism so please take this feedback for what > it's worth... > > > > Several points: > > > > 1. In general these seem useful, but I'm concerned that they may make > some unspecified assumptions... seemingly assuming that an html form is > always on the other side of the link without actually coming out and saying > so. > > I never saw it that way. Why do you think there is an HTML-form assumption? > > Just the overall impression I had on my initial read through, really. I cannot point to anything specific other than, perhaps, the language in Sections 3.1.1 and 3.2.1... perhaps a simple clarification on this point would be helpful in a future iteration, just to make it clear that no assumption is being made as to the type of resource being linked to. > > > > 2. create-form seems too specific to me at first review. Why not simply > "create" and allow the media type of the referenced resource specify > exactly what kind of thing it is. > > > > For example: > > > > Link: ; rel="create"; > type="application/atom+xml" > > > > Could potentially be used to tell me where to post new items to an > Atompub collection. > > > > Link: ; rel="create"; > type="text/html" > > Hmm, I think you are misreading the rels. They are only for finding the > form that tells me how to construct what I send to the creation (or update) > URI which I know already. > > No I got that part; all I was suggesting is that there is a possibly useful overlap with the more general case i illustrated. > > > > Essentially tells me that there's an HTML page presumably with > instructions or a form for editing. > > The question of the form format would be negotiated during the GET form > request/response roundtrip. The form could be available in many > representations, actually. > > Like I said, a simple clarification along these lines in the draft would be helpful :-) > > > > > If you went with this approach, the existing "edit" link relation could > similarly be used in place of "edit-form". Note that the definition of the > existing "edit" link relation is that it "refers to a resource that can be > used to edit the link's context"... seems like a pretty good fit to me. > > IIRC 'edit' has more the semantic of 'this is the primary URI of a > resource where you should turn to to make changes. I agree that you could > read atom that way, but seems like unclear wording to me. > > Yes.. I agree it's hazy... the point I'm making is that there's a very fuzzy line between "primary URI of a resource where you should turn to make changes" and "URI of the form where change can be made". It's just different ways of editing different types of resources. Currently, the "edit" link relations semantics are extremely fuzzy for anything other than atom resources and I have seen occasional instances of the "edit" link being used within html for exactly the same kind of use case as edit-form... tho admittedly such examples have been quite rare. I'm certainly not opposed to have the new link relations, but I would rather reuse existing ones if at all possible. > > > > Link: ; rel="edit"; > type="text/html" > > > > 3. I don't believe the requirements in sections 3.1.1 and 3.2.1 are > necessary at all. Nor is the error handling bit in section > > Yeah, was thinking the same. OTH, I found it interesting that Ioseb > thought of them and I had discussions yesterday that are directly answered > by these sections. > > Being thorough is good, but I think it makes too many assumptions about how the form on the other end of the link is represented and processed. There may not be a submission URI involved at all, for instance.. it all depends on what the representation of that form is and it's associated processing model, neither of which are assumed or defined by the draft. In other words, the spec is just fine without those sections. - James > Thanks for taking a look. > > Jan > > > > 3.3. > > > > - James > > > > > > On Tue, Oct 16, 2012 at 11:42 AM, Jan Algermissen < > jan.algermissen@nordsc.com> wrote: > > Hi, > > > > http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-08 > > > > I think the latest version of the draft is ready to go. I approve the > specified link relations. > > > > @Julian, @Mark: I am still lost process wise. What's next? > > > > Jan > > _______________________________________________ > > link-relations mailing list > > link-relations@ietf.org > > https://www.ietf.org/mailman/listinfo/link-relations > > > > --047d7b2e79c8e7ee7c04cc3ba90b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Oct 16, 2012 at 11:13 PM, Jan Algermissen <= ;jan.algerm= issen@nordsc.com> wrote:
Hi James,

On Oct 17, 2012, at 2:01 AM, James M Snell wrote:

> Just some quick feedback based on an initial read of the specification= ... Note: I have not had direct implementation experience

I do since yesterday :-) Suddenly popped up.

> with this particular mechanism so please take this feedback for what i= t's worth...
>
> Several points:
>
> 1. In general these seem useful, but I'm concerned that they may m= ake some unspecified assumptions... seemingly assuming that an html form is= always on the other side of the link without actually coming out and sayin= g so.

I never saw it that way. Why do you think there is an HTML-form assum= ption?


Just the overa= ll impression I had on my initial read through, really. I cannot point to a= nything specific other than, perhaps, the language in Sections 3.1.1 and 3.= 2.1... perhaps a simple clarification on this point would be helpful in a f= uture iteration, just to make it clear that no assumption is being made as = to the type of resource being linked to.
=C2=A0
>
> 2. create-form seems too specific to me at first review. Why not simpl= y "create" and allow the media type of the referenced resource sp= ecify exactly what kind of thing it is.
>
> For example:
>
> =C2=A0 Link: <http://example.org/atompub/collection>; rel=3D"c= reate"; type=3D"application/atom+xml"
>
> Could potentially be used to tell me where to post new items to an Ato= mpub collection.
>
> =C2=A0 Link: <http://example.org/html/foo.html>; rel=3D"create&qu= ot;; type=3D"text/html"

Hmm, I think you are misreading the rels. They are only for finding t= he form that tells me how to construct what I send to the creation (or upda= te) URI which I know already.


No I got that = part; all I was suggesting is that there is a possibly useful overlap with = the more general case i illustrated.
=C2=A0
>
> Essentially tells me that there's an HTML page presumably with ins= tructions or a form for editing.

The question of the form format would be negotiated during the GET fo= rm request/response roundtrip. The form could be available in many represen= tations, actually.


Like I said, a= simple clarification along these lines in the draft would be helpful :-)
=C2=A0

>
> If you went with this approach, the existing "edit" link rel= ation could similarly be used in place of "edit-form". Note that = the definition of the existing "edit" link relation is that it &q= uot;refers to a resource that can be used to edit the link's context&qu= ot;... seems like a pretty good fit to me.

IIRC 'edit' has more the semantic of 'this is the primary= URI of a resource where you should turn to to make changes. I agree that y= ou could read atom that way, but seems like unclear wording to me.


Yes.. I agree = it's hazy... the point I'm making is that there's a very fuzzy = line between "primary URI of a resource where you should turn to make = changes" and "URI of the form where change can be made". It&= #39;s just different ways of editing different types of resources.

Currently, the "edit" link relations semantic= s are extremely fuzzy for anything other than atom resources and I have see= n occasional instances of the "edit" link being used within html = for exactly the same kind of use case as edit-form... tho admittedly such e= xamples have been quite rare.

I'm certainly not opposed to have the new link rela= tions, but I would rather reuse existing ones if at all possible.
=C2=A0
>
> =C2=A0 Link: <http://example.org/html/edit.html>; rel=3D"edit&quo= t;; type=3D"text/html"
>
> 3. I don't believe the requirements in sections 3.1.1 and 3.2.1 ar= e necessary at all. Nor is the error handling bit in section

Yeah, was thinking the same. OTH, I found it interesting that Ioseb t= hought of them and I had discussions yesterday that are directly answered b= y these sections.


Being thorough is good, but I think it= makes too many assumptions about how the form on the other end of the link= is represented and processed. There may not be a submission URI involved a= t all, for instance.. it all depends on what the representation of that for= m is and it's associated processing model, neither of which are assumed= or defined by the draft. In other words, the spec is just fine without tho= se sections.

- James
=C2=A0
Thanks for taking a look.

Jan


> 3.3.
>
> - James
>
>
> On Tue, Oct 16, 2012 at 11:42 AM, Jan Algermissen <jan.algermissen@nordsc.com> wrote:
> Hi,
>
> http://tools.ietf.org/html/draft-ioseb-dzmanas= hvili-link-relation-08
>
> I think the latest version of the draft is ready to go. I approve the = specified link relations.
>
> @Julian, @Mark: I am still lost process wise. What's next?
>
> Jan
> _______________________________________________
> link-relations mailing list
> link-relations@ietf.org=
> https://www.ietf.org/mailman/listinfo/link-relations
>


--047d7b2e79c8e7ee7c04cc3ba90b-- From jasnell@gmail.com Wed Oct 17 00:05:07 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 156DC21F877A for ; Wed, 17 Oct 2012 00:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.761 X-Spam-Level: X-Spam-Status: No, score=-4.761 tagged_above=-999 required=5 tests=[AWL=-1.163, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7Uxb0eOAX2M for ; Wed, 17 Oct 2012 00:05:05 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 105CA21F875C for ; Wed, 17 Oct 2012 00:05:04 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id s14so6565457qcg.31 for ; Wed, 17 Oct 2012 00:05:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1wnpkgL+B2pPYhR8K75HZ16dxGGMGaMfIUqRzIdrfSE=; b=QSuRxJ5fZGkLFhCl6v4W+lWgzvJXWovyzeh8zQKlBd8Nt2r59PYxI31EQi6dLb1v1c PGEvs4eMBppKDNBPxGg9aviG2/CUuCNBnpyY3YhC3P1fF06+mLVYcdg5lNsy24hFZDea xNrdqy/rk6ypLRHxOq0pxuyNBYfzkAosSZTFYPsf3VwJkneVAopz/VtWz/ZeUFfY0BUx VTMHY2aRCdboJCobZjGHOoGvbLZ+HnUh3fW5vjoo3GqaOtBJ9TxMqmpF6U6KNIsKIpX8 S6AmPiJGo7Mbs/OQJ7c9E4lPNWhZBMHR9l2qeonh/IEHV7Jicxvz/l34RlxGXTL2ec0g gIPQ== Received: by 10.229.209.145 with SMTP id gg17mr8047618qcb.56.1350457504176; Wed, 17 Oct 2012 00:05:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.81.230 with HTTP; Wed, 17 Oct 2012 00:04:44 -0700 (PDT) In-Reply-To: References: <477A6BC0-58E6-4640-9CB6-E0FBAB66B493@nordsc.com> <0BEC80EE-F3AD-4898-85D5-595FE1472C4D@nordsc.com> From: James M Snell Date: Wed, 17 Oct 2012 00:04:44 -0700 Message-ID: Subject: Re: 'edit-form' and 'create-form' link relations To: Jan Algermissen Content-Type: multipart/alternative; boundary=005045015484d21bb204cc3be3b0 Cc: Ioseb Dzmanashvili , link-relations@ietf.org X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 07:05:07 -0000 --005045015484d21bb204cc3be3b0 Content-Type: text/plain; charset=UTF-8 The last thing I will note is that, while it's certainly something that has fallen out of style, there is some precedence to using "edit" link rels for this purpose... for historical reference, see http://universaleditbutton.org/Universal_Edit_Button. It's definitely not something that is in broad use today, but the same basic concepts were utilized and the use of the "edit" link relation was one of two main variations. You can even still find them around if you look hard enough [1] ;-). (It is humorous to note that the Universal Edit Button wiki itself does not appear to provide support for the Universal Edit Button) [1] view-source:http://c2.com/cgi/wiki?FrontPage On Tue, Oct 16, 2012 at 11:48 PM, James M Snell wrote: > > > On Tue, Oct 16, 2012 at 11:13 PM, Jan Algermissen < > jan.algermissen@nordsc.com> wrote: > >> Hi James, >> >> On Oct 17, 2012, at 2:01 AM, James M Snell wrote: >> >> > Just some quick feedback based on an initial read of the >> specification... Note: I have not had direct implementation experience >> >> I do since yesterday :-) Suddenly popped up. >> >> > with this particular mechanism so please take this feedback for what >> it's worth... >> > >> > Several points: >> > >> > 1. In general these seem useful, but I'm concerned that they may make >> some unspecified assumptions... seemingly assuming that an html form is >> always on the other side of the link without actually coming out and saying >> so. >> >> I never saw it that way. Why do you think there is an HTML-form >> assumption? >> >> > Just the overall impression I had on my initial read through, really. I > cannot point to anything specific other than, perhaps, the language in > Sections 3.1.1 and 3.2.1... perhaps a simple clarification on this point > would be helpful in a future iteration, just to make it clear that no > assumption is being made as to the type of resource being linked to. > > >> > >> > 2. create-form seems too specific to me at first review. Why not simply >> "create" and allow the media type of the referenced resource specify >> exactly what kind of thing it is. >> > >> > For example: >> > >> > Link: ; rel="create"; >> type="application/atom+xml" >> > >> > Could potentially be used to tell me where to post new items to an >> Atompub collection. >> > >> > Link: ; rel="create"; >> type="text/html" >> >> Hmm, I think you are misreading the rels. They are only for finding the >> form that tells me how to construct what I send to the creation (or update) >> URI which I know already. >> >> > No I got that part; all I was suggesting is that there is a possibly > useful overlap with the more general case i illustrated. > > >> > >> > Essentially tells me that there's an HTML page presumably with >> instructions or a form for editing. >> >> The question of the form format would be negotiated during the GET form >> request/response roundtrip. The form could be available in many >> representations, actually. >> >> > Like I said, a simple clarification along these lines in the draft would > be helpful :-) > > >> >> > >> > If you went with this approach, the existing "edit" link relation could >> similarly be used in place of "edit-form". Note that the definition of the >> existing "edit" link relation is that it "refers to a resource that can be >> used to edit the link's context"... seems like a pretty good fit to me. >> >> IIRC 'edit' has more the semantic of 'this is the primary URI of a >> resource where you should turn to to make changes. I agree that you could >> read atom that way, but seems like unclear wording to me. >> >> > Yes.. I agree it's hazy... the point I'm making is that there's a very > fuzzy line between "primary URI of a resource where you should turn to make > changes" and "URI of the form where change can be made". It's just > different ways of editing different types of resources. > > Currently, the "edit" link relations semantics are extremely fuzzy for > anything other than atom resources and I have seen occasional instances of > the "edit" link being used within html for exactly the same kind of use > case as edit-form... tho admittedly such examples have been quite rare. > > I'm certainly not opposed to have the new link relations, but I would > rather reuse existing ones if at all possible. > > >> > >> > Link: ; rel="edit"; >> type="text/html" >> > >> > 3. I don't believe the requirements in sections 3.1.1 and 3.2.1 are >> necessary at all. Nor is the error handling bit in section >> >> Yeah, was thinking the same. OTH, I found it interesting that Ioseb >> thought of them and I had discussions yesterday that are directly answered >> by these sections. >> >> > Being thorough is good, but I think it makes too many assumptions about > how the form on the other end of the link is represented and processed. > There may not be a submission URI involved at all, for instance.. it all > depends on what the representation of that form is and it's associated > processing model, neither of which are assumed or defined by the draft. In > other words, the spec is just fine without those sections. > > - James > > >> Thanks for taking a look. >> >> Jan >> >> >> > 3.3. >> > >> > - James >> > >> > >> > On Tue, Oct 16, 2012 at 11:42 AM, Jan Algermissen < >> jan.algermissen@nordsc.com> wrote: >> > Hi, >> > >> > http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-08 >> > >> > I think the latest version of the draft is ready to go. I approve the >> specified link relations. >> > >> > @Julian, @Mark: I am still lost process wise. What's next? >> > >> > Jan >> > _______________________________________________ >> > link-relations mailing list >> > link-relations@ietf.org >> > https://www.ietf.org/mailman/listinfo/link-relations >> > >> >> > --005045015484d21bb204cc3be3b0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The last thing I will note is that, wh= ile it's certainly something that has fallen out of style, there is som= e precedence to using "edit" link rels for this purpose... for hi= storical reference, see http://universaleditbutton.org/Universal_Edit_Button. It&= #39;s definitely not something that is in broad use today, but the same bas= ic concepts were utilized and the use of the "edit" link relation= was one of two main variations. You can even still find them around if you= look hard enough [1] ;-). (It is humorous to note that the Universal Edit = Button wiki itself does not appear to provide support for the Universal Edi= t Button)


On Tue, Oct 16, 2012 at 11:48 PM, James M Snell <jasnell@gmail.com>= wrote:


On Tue, Oct 16, 2012 at 11:13 PM, Jan Algermissen <jan.algermissen@nordsc.com> wrote:
Hi James,

On Oct 17, 2012, at 2:01 AM, James M Snell wrote:

> Just some quick feedback based on an initial read of the specification= ... Note: I have not had direct implementation experience

I do since yesterday :-) Suddenly popped up.

> with this particular mechanism so please take this feedback for what i= t's worth...
>
> Several points:
>
> 1. In general these seem useful, but I'm concerned that they may m= ake some unspecified assumptions... seemingly assuming that an html form is= always on the other side of the link without actually coming out and sayin= g so.

I never saw it that way. Why do you think there is an HTML-form assum= ption?


Just the overall impr= ession I had on my initial read through, really. I cannot point to anything= specific other than, perhaps, the language in Sections 3.1.1 and 3.2.1... = perhaps a simple clarification on this point would be helpful in a future i= teration, just to make it clear that no assumption is being made as to the = type of resource being linked to.
=C2=A0
>
> 2. create-form seems too specific to me at first review. Why not simpl= y "create" and allow the media type of the referenced resource sp= ecify exactly what kind of thing it is.
>
> For example:
>
> =C2=A0 Link: <http://example.org/atompub/collection>; rel=3D"c= reate"; type=3D"application/atom+xml"
>
> Could potentially be used to tell me where to post new items to an Ato= mpub collection.
>
> =C2=A0 Link: <http://example.org/html/foo.html>; rel=3D"create&qu= ot;; type=3D"text/html"

Hmm, I think you are misreading the rels. They are only for finding t= he form that tells me how to construct what I send to the creation (or upda= te) URI which I know already.


No I got that part; a= ll I was suggesting is that there is a possibly useful overlap with the mor= e general case i illustrated.
=C2=A0
>
> Essentially tells me that there's an HTML page presumably with ins= tructions or a form for editing.

The question of the form format would be negotiated during the GET fo= rm request/response roundtrip. The form could be available in many represen= tations, actually.


Like I said, a simple= clarification along these lines in the draft would be helpful :-)
=C2=A0

>
> If you went with this approach, the existing "edit" link rel= ation could similarly be used in place of "edit-form". Note that = the definition of the existing "edit" link relation is that it &q= uot;refers to a resource that can be used to edit the link's context&qu= ot;... seems like a pretty good fit to me.

IIRC 'edit' has more the semantic of 'this is the primary= URI of a resource where you should turn to to make changes. I agree that y= ou could read atom that way, but seems like unclear wording to me.


Yes.. I agree it'= s hazy... the point I'm making is that there's a very fuzzy line be= tween "primary URI of a resource where you should turn to make changes= " and "URI of the form where change can be made". It's j= ust different ways of editing different types of resources.

Currently, the "edit" link relations semantic= s are extremely fuzzy for anything other than atom resources and I have see= n occasional instances of the "edit" link being used within html = for exactly the same kind of use case as edit-form... tho admittedly such e= xamples have been quite rare.

I'm certainly not opposed to have the new link rela= tions, but I would rather reuse existing ones if at all possible.
=C2=A0
>
> =C2=A0 Link: <http://example.org/html/edit.html>; rel=3D"edit&quo= t;; type=3D"text/html"
>
> 3. I don't believe the requirements in sections 3.1.1 and 3.2.1 ar= e necessary at all. Nor is the error handling bit in section

Yeah, was thinking the same. OTH, I found it interesting that Ioseb t= hought of them and I had discussions yesterday that are directly answered b= y these sections.


Being thorough is good, but I th= ink it makes too many assumptions about how the form on the other end of th= e link is represented and processed. There may not be a submission URI invo= lved at all, for instance.. it all depends on what the representation of th= at form is and it's associated processing model, neither of which are a= ssumed or defined by the draft. In other words, the spec is just fine witho= ut those sections.

- James
=C2= =A0
Thanks for taking a look.

Jan


> 3.3.
>
> - James
>
>
> On Tue, Oct 16, 2012 at 11:42 AM, Jan Algermissen <jan.algermissen@nordsc.com<= /a>> wrote:
> Hi,
>
> http://tools.ietf.org/html/draft-ioseb-dzmanas= hvili-link-relation-08
>
> I think the latest version of the draft is ready to go. I approve the = specified link relations.
>
> @Julian, @Mark: I am still lost process wise. What's next?
>
> Jan
> _______________________________________________
> link-relations mailing list
> link-rela= tions@ietf.org
> https://www.ietf.org/mailman/listinfo/link-relations
>



--005045015484d21bb204cc3be3b0-- From dret@berkeley.edu Wed Oct 17 21:01:50 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7820A21F858F for ; Wed, 17 Oct 2012 21:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wztqd9PLaIuo for ; Wed, 17 Oct 2012 21:01:49 -0700 (PDT) Received: from cm02fe.IST.Berkeley.EDU (cm02fe.IST.Berkeley.EDU [169.229.218.143]) by ietfa.amsl.com (Postfix) with ESMTP id D980D21F858E for ; Wed, 17 Oct 2012 21:01:49 -0700 (PDT) Received: from cpe-66-8-228-36.hawaii.res.rr.com ([66.8.228.36] helo=dretair.local) by cm02fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1TOhIp-0004nM-6y; Wed, 17 Oct 2012 21:01:49 -0700 Message-ID: <507F7F27.2040609@berkeley.edu> Date: Wed, 17 Oct 2012 18:01:43 -1000 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: rfc-ise@rfc-editor.org Subject: independent submission of draft-wilde-profile-link Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: link-relations@ietf.org X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 04:01:50 -0000 dear RFC editor. according to the instructions on https://www.rfc-editor.org/indsubs.html, this is a submission for draft-wilde-profile-link to be published as an RFC. barry leiba has agreed to sponsor this draft (http://www.ietf.org/mail-archive/web/apps-discuss/current/msg07526.html). here is the information for the submission: * file name: draft-wilde-profile-link (i just submitted version -04 to make the switch to an informational RFC). * desired category: Informational * related discussion: several threads on http://www.ietf.org/mail-archive/web/apps-discuss/current/maillist.html, and the designated experts said that the draft met their expectations (http://www.ietf.org/mail-archive/web/link-relations/current/msg00400.html). * RFC 5226 considerations: IANA registration for the proposed link relation is required, but the designated experts for link relation registrations have agreed to accept the registration (http://www.ietf.org/mail-archive/web/link-relations/current/msg00400.html). please let me know if anything else is required, or whether the information in this email is sufficient for getting started with the RFC publication process. thanks and kind regards, erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From dret@berkeley.edu Wed Oct 17 21:11:57 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76CFC11E80A4 for ; Wed, 17 Oct 2012 21:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09GMyYY1FtSG for ; Wed, 17 Oct 2012 21:11:56 -0700 (PDT) Received: from cm04fe.IST.Berkeley.EDU (cm04fe.IST.Berkeley.EDU [169.229.218.145]) by ietfa.amsl.com (Postfix) with ESMTP id B524F21F85B1 for ; Wed, 17 Oct 2012 21:11:56 -0700 (PDT) Received: from cpe-66-8-228-36.hawaii.res.rr.com ([66.8.228.36] helo=dretair.local) by cm04fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1TOhSb-0002V1-FK; Wed, 17 Oct 2012 21:11:56 -0700 Message-ID: <507F8185.4010103@berkeley.edu> Date: Wed, 17 Oct 2012 18:11:49 -1000 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: rfc-ise@rfc-editor.org Subject: independent submission of draft-wilde-describes-link Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: link-relations@ietf.org X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 04:11:57 -0000 dear RFC editor. according to the instructions on https://www.rfc-editor.org/indsubs.html, this is a submission for draft-wilde-describes-link to be published as an RFC. barry leiba has agreed to sponsor this draft (http://www.ietf.org/mail-archive/web/link-relations/current/msg00380.html). here is the information for the submission: * file name: draft-wilde-describes-link (i just submitted version -02 to make the switch to an informational RFC). * desired category: Informational * related discussion: several threads on http://www.ietf.org/mail-archive/web/apps-discuss/current/maillist.html, and the designated experts said that the draft met their expectations (http://www.ietf.org/mail-archive/web/link-relations/current/msg00401.html). * RFC 5226 considerations: IANA registration for the proposed link relation is required, but the designated experts for link relation registrations have agreed to accept the registration (http://www.ietf.org/mail-archive/web/link-relations/current/msg00401.html). please let me know if anything else is required, or whether the information in this email is sufficient for getting started with the RFC publication process. thanks and kind regards, erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From jasnell@gmail.com Thu Oct 18 10:37:15 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17FD921F8470 for ; Thu, 18 Oct 2012 10:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.808 X-Spam-Level: X-Spam-Status: No, score=-4.808 tagged_above=-999 required=5 tests=[AWL=-1.210, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8+ZJWLiVgn+p for ; Thu, 18 Oct 2012 10:37:14 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 63DB121F846F for ; Thu, 18 Oct 2012 10:37:14 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id s14so7944681qcg.31 for ; Thu, 18 Oct 2012 10:37:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=cAktp0N4uz6mvDWg3T3K4T966FZUTnSHF+rM4Tlu9H4=; b=KaFsmEtNrP7Qj+OqIqQe4i4OAF5ZfZ7+zG0XHrt0m8+RhdFiEFWC/eGVhKNJsyWKbM fA+kfyyuCaSTlomSC6vsBD0ssqLdXsixLPueXS3oV3+HmRj0Y3MoaAts10Le27SJIBD2 Xg4GFoERL2LFs9mGUeACJlTOsvUKcOlAvT4wmExvvObIv/fO74YmpAwLgZt6UPZnS89x qOWF9Wj4co+rYhEHPt2j6wbFW/XFAqulT8Muh/UVXg4gpXhKtDp41QUpoSZoanuItgA+ QrLniRqK5fRdzZx2KEmhOyFjDDUVX+nFSBqkTwLfsRBORsNtYINHaN7JrT5zjP7GLZ2i Vzbw== Received: by 10.49.63.104 with SMTP id f8mr47587779qes.29.1350581833921; Thu, 18 Oct 2012 10:37:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.81.230 with HTTP; Thu, 18 Oct 2012 10:36:53 -0700 (PDT) From: James M Snell Date: Thu, 18 Oct 2012 10:36:53 -0700 Message-ID: Subject: Independent submission of draft-snell-additional-link-relations as Informational To: rfc-ise@rfc-editor.org, link-relations@ietf.org, Barry Leiba Content-Type: multipart/alternative; boundary=047d7bdc1a3a7373f504cc58d6bd X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 17:37:15 -0000 --047d7bdc1a3a7373f504cc58d6bd Content-Type: text/plain; charset=UTF-8 Dear RFC editor. according to the instructions on https://www.rfc-editor.org/**indsubs.html, this is a submission for draft-snell-additional-link-relations to be published as an RFC. Barry Leiba has agreed to sponsor this draft. here is the information for the submission: * file name: draft-snell-additional-link-relations [1] * desired category: Informational * related discussion: several threads on http://www.ietf.org/mail-** archive/web/apps-discuss/**current/maillist.html, and the designated experts said that the draft met their expectations [2] albeit with minor comments that, after review, I do not feel require additional modifications to the draft. * RFC 5226 considerations: IANA registration for the proposed link relation is required, but the designated experts for link relation registrations have agreed to accept the registration [2]. Please let me know if anything else is required. [1] http://tools.ietf.org/html/draft-snell-additional-link-relations-06 [2] http://www.ietf.org/mail-archive/web/link-relations/current/msg00402.html - James --047d7bdc1a3a7373f504cc58d6bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear RFC editor.

according to the instructions on=C2= =A0https://www.rfc-editor.org/indsubs.html, this is a submission= for=C2=A0draft-snell-additional-link-relations=C2=A0to be published as an = RFC. Barry Leiba has agreed to sponsor this draft. here is the information for the submission:

* file name:=C2=A0draft-snell-additional-link-relations=C2=A0[1]
* desired category: Informational
* related discussion: several threads on=C2=A0<= a href=3D"http://www.ietf.org/mail-archive/web/apps-discuss/current/maillis= t.html" style=3D"color:rgb(17,85,204);font-size:13.333333015441895px;font-f= amily:arial,sans-serif" target=3D"_blank">http://www.ietf.org/mail-a= rchive/web/apps-discuss/current/maillist.html.
* RFC 5226 considerations: IANA registration for the p= roposed link relation is required, but the designated experts for link rela= tion registrations have agreed to accept the registration [2].

Please let me know if anything else= is required.


- James --047d7bdc1a3a7373f504cc58d6bd-- From rfc-ise@rfc-editor.org Mon Oct 29 16:56:26 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8E8121F86CD for ; Mon, 29 Oct 2012 16:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FC-3oW9wEJWP for ; Mon, 29 Oct 2012 16:56:26 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1890:123a::1:14]) by ietfa.amsl.com (Postfix) with ESMTP id 5064421F86C3 for ; Mon, 29 Oct 2012 16:56:26 -0700 (PDT) Received: from localhost (c8a.amsl.com [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 3FDD712494A; Mon, 29 Oct 2012 16:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1CUPuqhv4RBC; Mon, 29 Oct 2012 16:56:26 -0700 (PDT) Received: from [130.216.38.131] (nevil-laptop1.sfac.auckland.ac.nz [130.216.38.131]) by c8a.amsl.com (Postfix) with ESMTPSA id ACF33124949; Mon, 29 Oct 2012 16:56:25 -0700 (PDT) Message-ID: <508F17A7.3060105@rfc-editor.org> Date: Tue, 30 Oct 2012 12:56:23 +1300 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: link-relations@ietf.org Subject: Request to publish draft-wmills-oauth-lrdd-06.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 30 Oct 2012 00:21:45 -0700 Cc: ISE X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 23:56:26 -0000 Hi Link Relations folk: William Mills has sent me this draft as an Independent Submission. The draft asks IANA to register link relations, so I'd like approval from the designated experts to proceed; would one of those experts please take a look at the draft for me? Please note that I'm asking this now instead of looking for a full review. IANA will - of course - ask the designated experts about it when the draft reaches the RFC Editor queue Cheers, Nevil -- Nevil Brownlee (ISE), rfc-ise@rfc-editor.org From julian.reschke@gmx.de Wed Oct 31 02:43:25 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E666A21F845F for ; Wed, 31 Oct 2012 02:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.519 X-Spam-Level: X-Spam-Status: No, score=-103.519 tagged_above=-999 required=5 tests=[AWL=-0.920, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lsg103SqVajp for ; Wed, 31 Oct 2012 02:43:25 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id DD6F821F845E for ; Wed, 31 Oct 2012 02:43:24 -0700 (PDT) Received: (qmail invoked by alias); 31 Oct 2012 09:43:23 -0000 Received: from p5DD9651D.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.101.29] by mail.gmx.net (mp033) with SMTP; 31 Oct 2012 10:43:23 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18QqeZ0FhoQFfahcELwCi3WMdQ6Mw3rJdpJB5EdQJ TCt9f8C0XbHamj Message-ID: <5090F2B9.6070507@gmx.de> Date: Wed, 31 Oct 2012 10:43:21 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Nevil Brownlee Subject: Re: Request to publish draft-wmills-oauth-lrdd-06.txt References: <508F17A7.3060105@rfc-editor.org> In-Reply-To: <508F17A7.3060105@rfc-editor.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: link-relations@ietf.org X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 09:43:26 -0000 On 2012-10-30 00:56, Nevil Brownlee wrote: > > Hi Link Relations folk: > > William Mills has sent me this draft as an Independent Submission. > > The draft asks IANA to register link relations, so I'd like approval > from the designated experts to proceed; would one of those experts > please take a look at the draft for me? > > Please note that I'm asking this now instead of looking for a full > review. IANA will - of course - ask the designated experts about it > when the draft reaches the RFC Editor queue > > Cheers, Nevil I have looked at the draft and have two editorial remarks: - the sections defining the link relation type should actually mention the name of the link relation being defined (minimally in the title) - also, they should more precisely link to the part of the spec where the actual definition is defined; right now it involves a bit of guessing / full-text search which shouldn't be required from the reader To actually understand what the link relations mean I'd have to understand OAuth which I do not. However I note that the link relations are prefixed "oauth" so I don't have a problem with these relation names being registered. Best regards, Julian