From darrel.miller@gmail.com Thu Jan 31 16:31:07 2013 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 BA56021F8A09 for ; Thu, 31 Jan 2013 16:31:07 -0800 (PST) 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 rJt2gi8oIUG6 for ; Thu, 31 Jan 2013 16:31:06 -0800 (PST) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA2D21F8A67 for ; Thu, 31 Jan 2013 16:31:05 -0800 (PST) Received: by mail-lb0-f175.google.com with SMTP id n3so4027046lbo.34 for ; Thu, 31 Jan 2013 16:31:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=YWpedIcJiaPIKmMF4wiuXAVttmDZQhUvZQiYTLry5Zg=; b=O1WCAiOTnEQ94BaI/qk/6n5yic53oGgO+LAlsb1ZaFsm/K6QtgPObOhZmQ01x99R9r RzG2l/PIDeYa3s0mj/U6orU3A4b0xvT0yaiYxvQ0chKddtqUVDym0wiaa4QPQVuKYMTT GfXoI8swjtgR3mFJO1E0Lad7bW2UTT9M/tRXVdolmOfuKKVcfmkolNWTDRiGeT2XhbbY LCqwLB78MgzIG/mfqlu3xkrN0dYFtUtaguqyYYSOBFvPyHHjSKKPpqmeSaI79+gigEjc 0s8hN2nt5PglF2338wb+NYwzVbEiqXky3eCYgGND3aYAJVc3Ug4TsouzF9Swq2dnF8G/ 9OvQ== MIME-Version: 1.0 X-Received: by 10.112.40.129 with SMTP id x1mr4082856lbk.95.1359678664963; Thu, 31 Jan 2013 16:31:04 -0800 (PST) Received: by 10.152.109.204 with HTTP; Thu, 31 Jan 2013 16:31:04 -0800 (PST) In-Reply-To: <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> Date: Thu, 31 Jan 2013 19:31:04 -0500 Message-ID: Subject: Re: NEW RELATION: action From: Darrel Miller To: Jan Algermissen Content-Type: multipart/alternative; boundary=e0cb4efe323ed5761a04d49edb1c X-Mailman-Approved-At: Fri, 01 Feb 2013 00:47:39 -0800 Cc: link-relations@ietf.org, Ioseb Dzmanashvili X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: darrel@tavis.ca List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 00:32:38 -0000 --e0cb4efe323ed5761a04d49edb1c Content-Type: text/plain; charset=ISO-8859-1 Hey Jan, I thought of you as soon as I saw this. I know we have traveled this road before and you are not a fan, but let me give you a few examples that I can think of and you let me know what "harm" they might cause. It can be used for changing a resource to a new state. > GET /light/bedroom > < 200 OK < Link : ; rel="action"; title="On" GET /survey/12321323/favouritefruit > < 200 OK < Content-Type: application/hal+xml Yes there are other ways of doing this, but I can't see any negative impacts on the system by using this approach. It can be used for triggering a part of a workflow process > GET /employee/344/timesheet/20130131 > < 200 OK < Content-Type: application/hal+xml I realize this last example steps into "it's not a self-descriptive request" territory, but let's not get sidetracked into that debate. The huge benefit in my mind of this link relation is that it opens the door for generic clients to be able to start doing some simple write operations. So far, most of the generic clients that people have been playing around with have been purely read-only. This link relation allows a generic client to display some buttons to a human and allow the human to "poke a stick" at the resource and actually have an impact. As I mentioned on twitter to Isoeb, I do think this link relation has the potential to be abused, however, I do believe it has sufficient value to mitigate those risks. Darrel On Thu, Jan 31, 2013 at 6:11 PM, Jan Algermissen wrote: > Hi Ioseb, > > can you explain your use case? > > To me this smells a lot like a (REST-) anti pattern. > > For example, instead of invoking an action resource like > > GET /content/article/22/publish > > you'd rather set it's state: > > PUT /content/article/22/publish > > > ... > published > ... > > > No need for link and 'action' link rel, because you know the resource to > change anyhow. > > > Maybe I am missing your point though. > > Jan > > > > On 31.01.2013, at 20:10, Ioseb Dzmanashvili > wrote: > > > Dear All, > > > > I've submitted new draft of the 'create' link relation type: > http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-00 > > > > Description: > > - The link relation is intentionally generic, and it can be used with > multiple media types in a wide variety of use cases. > > - When included in a resource which represents a collection, the 'form' > link relation identifies a target resource that represents the form for > adding a new member to the context collection. > > - The target IRI points to a resource that is responsible to perform an > action that may affect state of the context resource or > > initiate process. > > > > Could you please review? > > Thanks in advance! > > > > Best regards, > > ioseb > > -- > > Ioseb Dzmanashvili > > AzRy LLC > > Software Architect > > #8, Chachava str. > > Tbilisi, 0159, Georgia > > Mobile: +(995) 99753388 > > github.com/ioseb > > pecl.php.net/user/ioseb > > twitter.com/iosebi > > _______________________________________________ > > link-relations mailing list > > link-relations@ietf.org > > https://www.ietf.org/mailman/listinfo/link-relations > > _______________________________________________ > link-relations mailing list > link-relations@ietf.org > https://www.ietf.org/mailman/listinfo/link-relations > --e0cb4efe323ed5761a04d49edb1c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hey Jan,

I thought of you as soon= as I saw this. =A0I know we have=A0traveled=A0this road before and you are= not a fan, but let me give you a few examples that I can think of and you = let me know what "harm" they might cause. =A0

It can be used for changing a resource to a= new state.

> GET /light/bedroom
>
< 200 OK
< Link : = <http://example.org/ligh= t/bedroom/on>; rel=3D"action"; title=3D"On"
<Content-Type: text/plain
Off

This could absolutely be done with PUT, however the c= lient needs to be much smarter in order to know how to formulate the approp= riate body to submit a PUT request to do exactly the same thing. =A0

It can be used as a way of selecting from a= set of options

> GET /survey/12321= 323/favouritefruit
>
< 200 OK
< Content-Type: application/hal+xml

=A0 =A0 =A0 =A0 =A0 <link rel=3D"action" title=3D&q= uot;Orange" =A0href=3D"/survey/12321323/favouritefruit?answer=3DO= range" />=A0
=A0 =A0 =A0 =A0 =A0 <= link rel=3D"action" title=3D"Apple" =A0href=3D"/su= rvey/12321323/favouritefruit?answer=3DApple" />=A0
=A0 =A0 =A0 =A0 =A0 <link rel=3D"action" title= =3D"Banana" =A0href=3D"/survey/12321323/favouritefruit?answe= r=3DBanana" />=A0
</resource>
=

Yes there are other ways of doing this, but I can't see any = negative impacts on the system by using this approach.

=

It can be used for triggering a part = of a workflow process

> GET /employee/344/timesheet/20130= 131
>
< 200 OK
< Content-Type: appli= cation/hal+xml
=A0 =A0 =A0 =A0 =A0 <link rel=3D"action" title=3D"Su= bmit" =A0href=3D"/timesheetProcessor?timesheetid=3D21332434"= />=A0
</resource>


I realize this last example steps into "it's not a self-descriptiv= e request" territory, but let's not get sidetracked into that deba= te.

The huge benefit in my mind of thi= s link relation is that it opens the door for generic clients to be able to= start doing some simple write operations. =A0So far, most of the generic c= lients that people have been playing around with have been purely read-only= . =A0This link relation allows a generic client to display some buttons to = a human and allow the human to "poke a stick" at the resource and= actually have an impact.

As I mentioned on twitter to Isoeb, I do th= ink this link relation has the potential to be abused, however, I do believ= e it has sufficient value to mitigate those risks.

Darrel


On Thu, Jan 31, 2013 at 6:11 PM, Jan Algermissen <jan.algermissen@nordsc.com> wrote:
Hi Ioseb,

can you explain your use case?

To me this smells a lot like a (REST-) anti pattern.

For example, instead of invoking an action resource like

GET /content/article/22/publish

you'd rather set it's state:

PUT /content/article/22/publish

<entry>
...
<foo:status>published</foo:status>
...
</entry>

No need for link and 'action' link rel, because you know the resour= ce to change anyhow.


Maybe I am missing your point though.

Jan



On 31.01.2013, at 20:10, Ioseb Dzmanashvili <ioseb.dzmanashvili@gmail.com> wrote:

> Dear All,
>
> I've submitted new draft of the 'create' link relation typ= e: http://tools.ietf.org/html/draft-ioseb-dz= manashvili-action-link-relation-00
>
> Description:
> - The link relation is intentionally generic, and it can be used with = =A0multiple media types in a wide variety of use cases.
> - When included in a resource which represents a collection, the '= form' =A0link relation identifies a target resource that represents the= form for adding a new member to the context collection.
> - The target IRI points to a resource that is responsible to perform a= n action that may affect state of the context resource or
> =A0initiate process.
>
> Could you please review?
> Thanks in advance!
>
> Best regards,
> ioseb
> --
> Ioseb Dzmanashvili
> AzRy LLC
> Software Architect
> #8, Chachava str.
> Tbilisi, 0159, Georgia
> Mobile: +(995) 99753388
> github.com/ioseb=
> pecl.php.= net/user/ioseb
> twitter.com/io= sebi
> __________________= _____________________________
> link-relations mailing list
> link-relations@ietf.org=
> https://www.ietf.org/mailman/listinfo/link-relations

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

--e0cb4efe323ed5761a04d49edb1c-- From ioseb.dzmanashvili@gmail.com Fri Feb 1 01:44:40 2013 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 63FB921F8563 for ; Fri, 1 Feb 2013 01:44:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_72=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 NI-PKWFVHaS8 for ; Fri, 1 Feb 2013 01:44:38 -0800 (PST) Received: from mail-ee0-f42.google.com (mail-ee0-f42.google.com [74.125.83.42]) by ietfa.amsl.com (Postfix) with ESMTP id EC2D221F85B3 for ; Fri, 1 Feb 2013 01:44:37 -0800 (PST) Received: by mail-ee0-f42.google.com with SMTP id b47so2016451eek.29 for ; Fri, 01 Feb 2013 01:44:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:message-id:in-reply-to:references :subject:x-mailer:mime-version:content-type; bh=O/DYTOqua5Qh9gLamzXqyKo0J/WB3O+OHc6R7FVtpDY=; b=Hf1KrKz1NZreCkmkQwvjfhzMGtxdzf06+iQeXNvgxf0U4UiqWmqTSstQxF+1b4yIBb xcnh984JwkjfobgC2MESYeRmspeHXiFCemOm+BHMrGOpBdVXUiPIDFP1RRWssjDzVeto R35WRF953z9Bi+DJGpBVuafYCLT0uKV78WuXq2rMxn1KlDwHVjCkqoSMHWzh2Q13n9OZ suacwPy1suFRL1na2NXEqJFg6+RxQKu+ir6YK+DkDhjNreFMbx0qmMWK/hAyoLYXEkjf DIDbiCmS63iOgH9oJxbDDNOPK0g23mp5RUcKewHpFcs2pBZoSe4ipc+tp1LSVbBeLkoA 1TOg== X-Received: by 10.14.4.194 with SMTP id 42mr37837668eej.35.1359711876987; Fri, 01 Feb 2013 01:44:36 -0800 (PST) Received: from [10.131.33.116] ([213.131.60.234]) by mx.google.com with ESMTPS id g2sm11610075eep.16.2013.02.01.01.44.33 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 01 Feb 2013 01:44:34 -0800 (PST) Date: Fri, 1 Feb 2013 13:44:33 +0400 From: Ioseb Dzmanashvili To: darrel@tavis.ca Message-ID: <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> In-Reply-To: References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> Subject: Re: NEW RELATION: action X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="510b8e81_74087021_28a" 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: Fri, 01 Feb 2013 09:44:40 -0000 --510b8e81_74087021_28a Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Jan, Thanks for feedback! > can you explain your use case? Example one(publishing content): > GET /posts/1 > Host: domain.org < HTTP/1.1 200 OK < Content-Type: application/something < Content-Length: ... < Link: ; rel="action"; title="Publish" [BODY HERE] > POST /posts/1/publisher HTTP/1.1 > Host: domain.org < HTTP/1.1 303 See Other < Location: http://domain.org/posts/1 Example two(restarting service): > GET /service HTTP/1.1 > Host: domain.org < HTTP/1.1 200 OK < Content-Type: ... < Content-Length: ... < Link: ; rel="action urn:restart"; title="Restart" [BODY HERE] > POST /service/manager HTTP/1.1 > Host: domain.org < HTTP/1.1 202 Accepted < Retry-After: 10 < Link: ; rel="monitor" I hope these examples clearly demonstrate purpose of the "action" link relation. > To me this smells a lot like a (REST-) anti pattern. I do not agree. Which REST constraint is violated in this case? Using POST without body is valid and "action" links expose availability of actions which may be performed: * without knowing media type; * without need to construct whole message(to conform PUT's replace semantics); * no need to use PATCH * "action" links can be filtered by client and displayed to user(and here we do not even need additional link relation extensions) In addition let me show another example: > GET /posts HTTP/1.1 > Host: domain.org > HTTP/1.1 200 OK > Content-Type: application/vnd.something+json > Content-Length: ... {"document": { "href": "/posts" "links": { "item": [{ "href": "/posts/1", "title": "Post One Title", "links": { "action": { "href": "/posts/1/publisher", "title": "Publish" }, "replies": { "href": "/posts/1/replies", "title": "Comments" }, "edit": { "href": "/posts/1", "title": "Edit post" } } }, { "href": "/posts/2", "title": "Post Two Title", "links": { "action": { "href": "/posts/2/publisher", "title": "Publish" }, "replies": { "href": "/posts/2/replies", "title": "Comments" }, "edit": { "href": "/posts/2", "title": "Edit post" } } }] } }} Here we have document with hierarchical links(no specific format, just format i frequently use for my implementations). Now if i want to present these links visually i've all information which may be perfectly rendered on mobile devices, for example lets say simple list. Post title is enough for application user. The "action" link relation has enough semantics for application to render it as a "Publish" button alongside the title and if user decides to "publish" the post there is no need for application to: a) go to the server and retrieve full representation in whatever media type; b) modify only one attribute of the retrieved representatin; and c) send modified representation to the server with PUT method. Instead simple POST request can be sent to the resource which knows what to do with the post's state. I hope these examples and explanations will help. Thanks again for feedback! @Darrel Thank you very much for positive feedback! Best regards, ioseb On Friday, February 1, 2013 at 4:31 AM, Darrel Miller wrote: > Hey Jan, > > I thought of you as soon as I saw this. I know we have traveled this road before and you are not a fan, but let me give you a few examples that I can think of and you let me know what "harm" they might cause. > > It can be used for changing a resource to a new state. > > > GET /light/bedroom > > > < 200 OK > < Link : ; rel="action"; title="On" > Off > > This could absolutely be done with PUT, however the client needs to be much smarter in order to know how to formulate the appropriate body to submit a PUT request to do exactly the same thing. > > It can be used as a way of selecting from a set of options > > > GET /survey/12321323/favouritefruit > > > < 200 OK > < Content-Type: application/hal+xml > > > > > > > > > Yes there are other ways of doing this, but I can't see any negative impacts on the system by using this approach. > > > It can be used for triggering a part of a workflow process > > > GET /employee/344/timesheet/20130131 > > > < 200 OK > < Content-Type: application/hal+xml > > > > > > > I realize this last example steps into "it's not a self-descriptive request" territory, but let's not get sidetracked into that debate. > > The huge benefit in my mind of this link relation is that it opens the door for generic clients to be able to start doing some simple write operations. So far, most of the generic clients that people have been playing around with have been purely read-only. This link relation allows a generic client to display some buttons to a human and allow the human to "poke a stick" at the resource and actually have an impact. > > As I mentioned on twitter to Isoeb, I do think this link relation has the potential to be abused, however, I do believe it has sufficient value to mitigate those risks. > > Darrel > > > On Thu, Jan 31, 2013 at 6:11 PM, Jan Algermissen wrote: > > Hi Ioseb, > > > > can you explain your use case? > > > > To me this smells a lot like a (REST-) anti pattern. > > > > For example, instead of invoking an action resource like > > > > GET /content/article/22/publish > > > > you'd rather set it's state: > > > > PUT /content/article/22/publish > > > > > > ... > > published > > ... > > > > > > No need for link and 'action' link rel, because you know the resource to change anyhow. > > > > > > Maybe I am missing your point though. > > > > Jan > > > > > > > > On 31.01.2013, at 20:10, Ioseb Dzmanashvili wrote: > > > > > Dear All, > > > > > > I've submitted new draft of the 'create' link relation type: http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-00 > > > > > > Description: > > > - The link relation is intentionally generic, and it can be used with multiple media types in a wide variety of use cases. > > > - When included in a resource which represents a collection, the 'form' link relation identifies a target resource that represents the form for adding a new member to the context collection. > > > - The target IRI points to a resource that is responsible to perform an action that may affect state of the context resource or > > > initiate process. > > > > > > Could you please review? > > > Thanks in advance! > > > > > > Best regards, > > > ioseb > > > -- > > > Ioseb Dzmanashvili > > > AzRy LLC > > > Software Architect > > > #8, Chachava str. > > > Tbilisi, 0159, Georgia > > > Mobile: +(995) 99753388 > > > github.com/ioseb (http://github.com/ioseb) > > > pecl.php.net/user/ioseb (http://pecl.php.net/user/ioseb) > > > twitter.com/iosebi (http://twitter.com/iosebi) > > > _______________________________________________ > > > link-relations mailing list > > > link-relations@ietf.org (mailto:link-relations@ietf.org) > > > https://www.ietf.org/mailman/listinfo/link-relations > > > > _______________________________________________ > > link-relations mailing list > > link-relations@ietf.org (mailto:link-relations@ietf.org) > > https://www.ietf.org/mailman/listinfo/link-relations > --510b8e81_74087021_28a Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Jan, 

Thanks f= or feedback=21 

> can you explain your u= se case=3F

Example one(publishing content):

> GET /posts/1
> Host: domain.org

< HTTP/1.1 200 OK
< Content-Type: = application/something
< Content-Length: ...
< L= ink: </posts/1/publisher urn:publish>; rel=3D=22action=22; title=3D= =22Publish=22

=5BBODY HERE=5D

> POST /posts/1/publisher HTTP/1.1
> Host: domain.= org

< HTTP/1.1 303 See Other
< L= ocation: http://domain.org/posts/1

Example two(r= estarting service):

> GET /service HTTP/1.1
> Host: domain.org

< HTTP/1.1 200= OK
< Content-Type: ...
< Content-Length: ...
< Link: </service/manager>; rel=3D=22action urn:restart= =22; title=3D=22Restart=22

=5BBODY HERE=5D
=

> POST /service/manager HTTP/1.1
> Ho= st: domain.org

< HTTP/1.1 202 Accepted
<= div>< Retry-After: 10
< Link: </service/status>; re= l=3D=22monitor=22

I hope these examples clearly = demonstrate purpose of the =22action=22 link relation. 
> To me this smells a lot like a (REST-) anti pattern.

I do not agree. Which REST constraint is violated = in this case=3F Using POST without body is valid and =22action=22 links e= xpose availability of actions which may be performed: 
* without knowing media type;
* without need to con= struct whole message(to conform PUT's replace semantics);
* no = need to use PATCH 
* =22action=22 links can be filtered by= client and displayed to user(and here we do not even need additional lin= k relation extensions)

In addition let me show a= nother example: 

> GET /posts HTTP/1.1
> Host: domain.org

> HTTP/1.1 200= OK
> Content-Type: application/vnd.something+json
> Content-Length: ...

=7B=22document=22: =7B=
=22href=22: =22/posts=22
=22links=22: =7B
=22= item=22: =5B=7B
=22href=22: =22/posts/1=22,
=22ti= tle=22: =22Post One Title=22,
=22links=22: =7B
=22= action=22: =7B =22href=22: =22/posts/1/publisher=22, =22title=22: =22Publ= ish=22 =7D,
=22replies=22: =7B =22href=22: =22/posts/1/repli= es=22, =22title=22: =22Comments=22 =7D,
=22edit=22: =7B =22h= ref=22: =22/posts/1=22, =22title=22: =22Edit post=22 =7D
=7D<= /div>
=7D, =7B
=22href=22: =22/posts/2=22,
=22= title=22: =22Post Two Title=22,
=22links=22: =7B
=22action=22: =7B =22href=22: =22/posts/2/publisher=22, =22title=22: =22= Publish=22 =7D,
=22replies=22: =7B =22href=22: =22/posts/2/r= eplies=22, =22title=22: =22Comments=22 =7D,
=22edit=22: =7B = =22href=22: =22/posts/2=22, =22title=22: =22Edit post=22 =7D
= =7D
=7D=5D
=7D
=7D=7D

Here we have document with hierarchical links(no specific format, just= format i frequently use for my implementations). Now if i want to presen= t these links visually i've all information which may be perfectly render= ed on mobile devices, for example lets say simple list. Post title is eno= ugh for application user. The =22action=22 link relation has enough seman= tics for application to render it as a =22Publish=22 button alongside the= title and if user decides to =22publish=22 the post there is no need for= application to: a) go to the server and retrieve full representation in = whatever media type; b) modify only one attribute of the retrieved repres= entatin; and c) send modified representation to the server with PUT metho= d. Instead simple POST request can be sent to the resource which knows wh= at to do with the post's state. 

I hope the= se examples and explanations will help. Thanks again for feedback=21

=40Darrel
Thank you very much for positive= feedback=21

Best regards,
ioseb
=
=20

On =46riday, =46ebruar= y 1, 2013 at 4:31 AM, Darrel Miller wrote:

Hey Jan,
I thought of you as soon as I saw this.  = I know we have traveled this road before and you are not a fan,= but let me give you a few examples that I can think of and you let me kn= ow what =22harm=22 they might cause.  

It can be used for chan= ging a resource to a new state.

> GET /light/bedroom
>
=
< 200 OK
< Link : <= http://example.org/li= ght/bedroom/on>; rel=3D=22action=22; title=3D=22On=22
<Content-Type: text/plain
Off

This could ab= solutely be done with PUT, however the client needs to be much smarter in= order to know how to formulate the appropriate body to submit a PUT requ= est to do exactly the same thing.  

It can be used as a way= of selecting from a set of options

> GET /survey/12321323/favouritefruit
>
< 200 OK
< Content-Type: application/hal+xml

          <link rel=3D=22= action=22 title=3D=22Orange=22  href=3D=22/survey/12321323/favourite= fruit=3Fanswer=3DOrange=22 /> 
=
          <link rel=3D=22action=22 title= =3D=22Apple=22  href=3D=22/survey/12321323/favouritefruit=3Fanswer=3D= Apple=22 /> 
          <link rel=3D=22acti= on=22 title=3D=22Banana=22  href=3D=22/survey/12321323/favouritefrui= t=3Fanswer=3DBanana=22 /> 
</resource>
<= /div>

Yes there are other ways of doing this, but I can't s= ee any negative impacts on the system by using this approach.


It can be used for triggering a part of a workflow process

> GET /employee= /344/timesheet/20130131
>
< 200 OK
&l= t; Content-Type: application/hal+xml

=
          <link rel=3D=22action=22 title= =3D=22Submit=22  href=3D=22/timesheetProcessor=3Ftimesheetid=3D21332= 434=22 /> 
</resource>


I realize this last example steps into =22it's not a self-descriptive req= uest=22 territory, but let's not get sidetracked into that debate.
<= div style=3D=22=22>
The huge benefit in my m= ind of this link relation is that it opens the door for generic clients t= o be able to start doing some simple write operations.  So far, most= of the generic clients that people have been playing around with have be= en purely read-only.  This link relation allows a generic client to = display some buttons to a human and allow the human to =22poke a stick=22= at the resource and actually have an impact.

As I mentioned on twitter to Iso= eb, I do think this link relation has the potential to be abused, however= , I do believe it has sufficient value to mitigate those risks.

Darrel


On Thu, Jan= 31, 2013 at 6:11 PM, Jan Algermissen <jan.alg= ermissen=40nordsc.com> wrote:
Hi Ioseb,

can you explain your use case=3F

To me this smells a lot like a (REST-) anti pattern.

=46or example, instead of invoking an action resource like

GET /content/article/22/publish

you'd rather set it's state:

PUT /content/article/22/publish

<entry>
...
<foo:status>published</foo:status>
...
</entry>

No need for link and 'action' link rel, because you know the resource to = change anyhow.


Maybe I am missing your point though.

Jan



On 31.01.2013, at 20:10, Ioseb Dzmanashvili <ioseb.dzmanashvili=40gmail.com> wrote= :

> Dear All,
>
> I've submitted new draft of the 'create' link relation type: http://tools.ietf.org/html/draft-iose= b-dzmanashvili-action-link-relation-00
>
> Description:
> - The link relation is intentionally generic, and it can be used wit= h  multiple media types in a wide variety of use cases.
> - When included in a resource which represents a collection, the 'fo= rm'  link relation identifies a target resource that represents the = form for adding a new member to the context collection.
> - The target IRI points to a resource that is responsible to perform= an action that may affect state of the context resource or
>  initiate process.
>
> Could you please review=3F
> Thanks in advance=21
>
> Best regards,
> ioseb
> --
> Ioseb Dzmanashvili
> AzRy LLC
> Software Architect
> =238, Chachava str.
> Tbilisi, 0159, Georgia
> Mobile: +(995) 99753388
> gith= ub.com/ioseb
> pecl.php.net/user/ioseb
> tw= itter.com/iosebi
> =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 mailing list
> link-relations=40ie= tf.org
> https://www.ietf.org/mailman/listinfo/link-relat= ions

=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 mailing list
link-relations=40ietf.or= g
https://www.ietf.org/mailman/listinfo/link-relations<= /a>

=20 =20 =20 =20 =20

--510b8e81_74087021_28a-- From markus.lanthaler@gmx.net Fri Feb 1 03:31:35 2013 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 65F0221F854C for ; Fri, 1 Feb 2013 03:31:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.55 X-Spam-Level: X-Spam-Status: No, score=-0.55 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_72=0.6, MSGID_MULTIPLE_AT=1.449] 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 D8WDyEIJlAXK for ; Fri, 1 Feb 2013 03:31:34 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4A421F8549 for ; Fri, 1 Feb 2013 03:31:34 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.19]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LiZpS-1UZCcD3cbM-00cipS for ; Fri, 01 Feb 2013 12:31:33 +0100 Received: (qmail invoked by alias); 01 Feb 2013 11:31:33 -0000 Received: from 84-115-182-43.dynamic.surfer.at (EHLO Vostro3500) [84.115.182.43] by mail.gmx.net (mp019) with SMTP; 01 Feb 2013 12:31:33 +0100 X-Authenticated: #419883 X-Provags-ID: V01U2FsdGVkX18U9zoUOBAU13j/Ysq3f3FaW9/mRJzWKILNBMm4/L 0+DHGHpJUW360n From: "Markus Lanthaler" To: "'Ioseb Dzmanashvili'" References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> In-Reply-To: <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> Subject: RE: NEW RELATION: action Date: Fri, 1 Feb 2013 12:31:27 +0100 Message-ID: <01a701ce006f$ad6aa3a0$083feae0$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4AYMOrAwan74NgTvScvCA9N/kD0QADWx1w Content-Language: de X-Y-GMX-Trusted: 0 Cc: darrel@tavis.ca, 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: Fri, 01 Feb 2013 11:31:35 -0000 On Friday, February 01, 2013 10:45 AM, Ioseb Dzmanashvili wrote: > > To me this smells a lot like a (REST-) anti pattern. > > I do not agree. Which REST constraint is violated in this case? > Using POST without body is valid and "action" links expose > availability of actions which may be performed:=20 > > * without knowing media type; > * without need to construct whole message(to conform PUT's > replace semantics); > * no need to use PATCH=20 > * "action" links can be filtered by client and displayed to > user(and here we do not even need additional link relation > extensions) The problem is they can just be filtered by clients who know about them. = How would a generic crawler know it has to avoid those action links? For = example, looking at your example: < HTTP/1.1 200 OK < Content-Type: ... < Content-Length: ... < Link: ; rel=3D"action urn:restart"; = title=3D"Restart" Imagine that the link would be embedded in a HTML page: Restart What would happen if a crawler follows that link? Would the service be = restarted? Assuming that you say links with this relation type just = accept POST (and I think that's what Jan was concerned about because it = wasn't clear in your initial mail), would it result in an error because = it uses GET? On Friday, February 1, 2013 at 4:31 AM, Darrel Miller wrote: > Yes there are other ways of doing this, but I can't see any > negative impacts on the system by using this approach. > > [..] > > The huge benefit in my mind of this link relation is that it > opens the door for generic clients to be able to start doing > some simple write operations. =20 Talking about HTML, how is that different from using an empty form (just = submit button) and @method=3DPOST? -- Markus Lanthaler @markuslanthaler From ioseb.dzmanashvili@gmail.com Fri Feb 1 03:43:03 2013 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 71D1621F86A8 for ; Fri, 1 Feb 2013 03:43:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, J_CHICKENPOX_72=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 b9alCYWhL2LF for ; Fri, 1 Feb 2013 03:43:02 -0800 (PST) Received: from mail-ea0-f173.google.com (mail-ea0-f173.google.com [209.85.215.173]) by ietfa.amsl.com (Postfix) with ESMTP id 5FFEE21F86A1 for ; Fri, 1 Feb 2013 03:43:02 -0800 (PST) Received: by mail-ea0-f173.google.com with SMTP id i1so1688489eaa.18 for ; Fri, 01 Feb 2013 03:43:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:message-id:in-reply-to:references :subject:x-mailer:mime-version:content-type; bh=vpc1t2JD6NQ+hAx6YZfINyVXzc2QpvlrGdIyfdPWR1s=; b=z8aTkbcWidal3+bYe3nRp/R4pHq1Fr0xUdWnXMU4sAcE2gGHg/GOJFsPCsNLzQS6M2 /xQNRl7YBVu5Ja89NIvES3jrnd95dQeZ7wh9AJL59Sf58Jxqgr+ToK+1xSYn2OVgfdqS eMeERwJ41PNJgPoFuLbbzuvxq/VLGnh5ChVVP7Ye5NsNJT/SUpL+M6LFUCVOYPpB0tYP +ZAeCahPjzMfsQyYt3Xrsvn/U8kRueA4isfbXVyVWAfiPPs1TYeNjZZRwXtocmrZAYNo +rYJEBpp/yDX7IsSmFXc5jDJ+Oez4V9NlL7AvSnrqDpQgyOXTq4dVJ+bl58JYSIBno6Z QqXA== X-Received: by 10.14.223.137 with SMTP id v9mr38917802eep.22.1359718981523; Fri, 01 Feb 2013 03:43:01 -0800 (PST) Received: from [10.131.33.116] ([213.131.60.234]) by mx.google.com with ESMTPS id t44sm12139628eeo.2.2013.02.01.03.42.51 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 01 Feb 2013 03:43:00 -0800 (PST) Date: Fri, 1 Feb 2013 15:42:51 +0400 From: Ioseb Dzmanashvili To: Markus Lanthaler Message-ID: <084F8A1FB98040A1BD1B987D3CF3D518@gmail.com> In-Reply-To: <510ba796.09df0e0a.3a70.fffff0f4SMTPIN_ADDED_BROKEN@mx.google.com> References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> <510ba796.09df0e0a.3a70.fffff0f4SMTPIN_ADDED_BROKEN@mx.google.com> Subject: Re: NEW RELATION: action X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="510baa3b_1575811c_28a" Cc: darrel@tavis.ca, 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: Fri, 01 Feb 2013 11:43:03 -0000 --510baa3b_1575811c_28a Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Markus, Draft doesn't mention anything about GET request to "action" links for the moment, though i think service implementors can use: 3xx status codes to redirect user agent somewhere else, return 4xx(405 Method Not Allowed for example) etc.... But the action must be performed only if client sends POST request. P.S. i truly believe that such links must not be exposed to public unless client doesn't have enough permissions. Cheers, ioseb On Friday, February 1, 2013 at 3:31 PM, Markus Lanthaler wrote: > On Friday, February 01, 2013 10:45 AM, Ioseb Dzmanashvili wrote: > > > > To me this smells a lot like a (REST-) anti pattern. > > > > I do not agree. Which REST constraint is violated in this case? > > Using POST without body is valid and "action" links expose > > availability of actions which may be performed: > > > > * without knowing media type; > > * without need to construct whole message(to conform PUT's > > replace semantics); > > * no need to use PATCH > > * "action" links can be filtered by client and displayed to > > user(and here we do not even need additional link relation > > extensions) > > > > > The problem is they can just be filtered by clients who know about them. How would a generic crawler know it has to avoid those action links? For example, looking at your example: > > > < HTTP/1.1 200 OK > < Content-Type: ... > < Content-Length: ... > < Link: ; rel="action urn:restart"; title="Restart" > > Imagine that the link would be embedded in a HTML page: > > Restart > > What would happen if a crawler follows that link? Would the service be restarted? Assuming that you say links with this relation type just accept POST (and I think that's what Jan was concerned about because it wasn't clear in your initial mail), would it result in an error because it uses GET? > > > On Friday, February 1, 2013 at 4:31 AM, Darrel Miller wrote: > > > Yes there are other ways of doing this, but I can't see any > > negative impacts on the system by using this approach. > > > > [..] > > > > The huge benefit in my mind of this link relation is that it > > opens the door for generic clients to be able to start doing > > some simple write operations. > > > > > Talking about HTML, how is that different from using an empty form (just submit button) and @method=POST? > > > > > -- > Markus Lanthaler > @markuslanthaler > > --510baa3b_1575811c_28a Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Markus, 

Draft does= n't mention anything about GET request to =22action=22 links for the mome= nt, though i think service implementors can use: 3xx status codes to redi= rect user agent somewhere else, return 4xx(405 Method Not Allowed for exa= mple) etc.... But the action must be performed only if client sends POST = request.

P.S.
i truly believe that suc= h links must not be exposed to public unless client doesn't have enough p= ermissions. 

Cheers,
ioseb <= /div> =20

On =46riday, =46ebruar= y 1, 2013 at 3:31 PM, Markus Lanthaler wrote:

On =46riday, =46ebruary 01, 2013= 10:45 AM, Ioseb Dzmanashvili wrote:

To me this smells a= lot like a (REST-) anti pattern.

I= do not agree. Which REST constraint is violated in this case=3F
Using POST without body is valid and =22action=22 links expose
availability of actions which may be performed:

* without knowing media type;
* without need to construct wh= ole message(to conform PUT's
replace semantics);
* = no need to use PATCH
* =22action=22 links can be filtered by c= lient and displayed to
user(and here we do not even need additi= onal link relation
extensions)
The problem is they can just be filtered by clients who know = about them. How would a generic crawler know it has to avoid those action= links=3F =46or example, looking at your example:


< HTTP/1.1 200 OK
< Content-Type: ...
< Content-Length: ...
< Link: </service/manage= r>; rel=3D=22action urn:restart=22; title=3D=22Restart=22
Imagine that the link would be embedded in a HTML page:

<a href=3D=22/service/manager=22 rel=3D=22action = urn:restart=22>Restart</a>

What would h= appen if a crawler follows that link=3F Would the service be restarted=3F= Assuming that you say links with this relation type just accept POST (an= d I think that's what Jan was concerned about because it wasn't clear in = your initial mail), would it result in an error because it uses GET=3F


On =46riday, =46ebruary 1, 2013 at = 4:31 AM, Darrel Miller wrote:

Yes there are other ways of doing this, but I can't see = any
negative impacts on the system by using this approach.

=5B..=5D

The huge benefit i= n my mind of this link relation is that it
opens the door for g= eneric clients to be able to start doing
some simple write oper= ations.

Talking about HTML= , how is that different from using an empty form (just submit button) and= =40method=3DPOST=3F




--
Markus Lanthaler
=40markuslantha= ler
=20 =20 =20 =20 =20

--510baa3b_1575811c_28a-- From darrel.miller@gmail.com Fri Feb 1 05:28:22 2013 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 D861C21F8C03 for ; Fri, 1 Feb 2013 05:28:22 -0800 (PST) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 S5US1OYjEFNQ for ; Fri, 1 Feb 2013 05:28:22 -0800 (PST) Received: from mail-la0-x22f.google.com (la-in-x022f.1e100.net [IPv6:2a00:1450:4010:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id ACA6021F8CE2 for ; Fri, 1 Feb 2013 05:28:21 -0800 (PST) Received: by mail-la0-f47.google.com with SMTP id fj20so2813616lab.34 for ; Fri, 01 Feb 2013 05:28:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:date:message-id:subject:from:to :content-type; bh=KeNE6i2Eh/9CxsEeLpnAFMyYAhnqzFyyckMMjX4JU7U=; b=lJEgMKOYAeYCJ+0InINPCw5Z3dni1+OuzU49IHqdF3F6BqGzrhmDHo578vFOR2svD2 iaTjkeFv+t2SSu1eHd20lNzUOaNlnhtPD2TUolat/9+Vt38hAgImJhObiEK4IOc9kJuy ke00xtFLFZDFFBPVyUpPAEqQJNos1mWREKdrofKDvJphiWZI5pxzVb7R5KxdSwdMfugV 2+0nkKOc+JVRqU8tFiVERP3LM1NEWHDIOX/V5wsa9lKU29uX1KRt7E9L6F/apnmyvD/3 ss30pSXPk2UjywDAX+cGQ9X23H84Q/7nOJXnNa/yGiDQ/u2TbXOrWOO0cH+jjkhNOl4n WX0Q== MIME-Version: 1.0 X-Received: by 10.112.99.197 with SMTP id es5mr4808151lbb.30.1359725300405; Fri, 01 Feb 2013 05:28:20 -0800 (PST) Received: by 10.152.109.204 with HTTP; Fri, 1 Feb 2013 05:28:16 -0800 (PST) Date: Fri, 1 Feb 2013 08:28:16 -0500 Message-ID: Subject: NEW RELATION: action From: Darrel Miller To: link-relations Content-Type: multipart/alternative; boundary=f46d0401727185d6fb04d4a9b7b9 X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: darrel@tavis.ca List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 13:28:23 -0000 --f46d0401727185d6fb04d4a9b7b9 Content-Type: text/plain; charset=ISO-8859-1 Markus, On Fri, Feb 1, 2013 at 6:31 AM, Markus Lanthaler wrote: > > Talking about HTML, how is that different from using an empty form (just > submit button) and @method=POST? > > It isn't different. It allows that same functionality to be embedded in any hypermedia type, Or even just in link headers. I think the fact that you can do it in HTML further validates this proposal. Darrel --f46d0401727185d6fb04d4a9b7b9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Markus,


On Fri, Feb 1, 2013 at 6:31 AM, Markus Lanthaler = <markus.la= nthaler@gmx.net> wrote:

Talking about HTML, how is th= at different from using an empty form (just submit button) and @method=3DPO= ST?


It isn't different. =A0It al= lows that same functionality to be embedded in any hypermedia type, Or even= just in link headers. =A0I think the fact that you can do it in HTML furth= er validates this proposal.

Darrel=A0
=A0
=

--f46d0401727185d6fb04d4a9b7b9-- From darrel.miller@gmail.com Fri Feb 1 05:30:28 2013 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 157B921F8D86 for ; Fri, 1 Feb 2013 05:30:28 -0800 (PST) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 whPaUeAk37+W for ; Fri, 1 Feb 2013 05:30:27 -0800 (PST) Received: from mail-la0-x22b.google.com (la-in-x022b.1e100.net [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 4E00D21F8D57 for ; Fri, 1 Feb 2013 05:30:27 -0800 (PST) Received: by mail-la0-f43.google.com with SMTP id ek20so2764552lab.2 for ; Fri, 01 Feb 2013 05:30:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=YVvoiSxgpESEq5hNhwtHYcODxHnbSRv7YIeWdV7HoVk=; b=WagIlA0l9EMvI6eV+vDZcYSrkjU/ivrBvJCqRytrmxuDjmNo7mrKy9ALsrdlbq83Us zva5yfqoPGpIHDOIPHPq4UXRxxL6CsXat6QSI3KnwLmXRZrjZr+EEl6QKHcloxT+EP5J 7rrG3zh0ZY1A0snZESlap2AhVTMAZtj31R0G9967WYGTjDIJL8RqK+aScBQxFzRZ1xFa j+wP8Y/z7rqv/a4Ex5+cde7fw+G7Fl/ATVBHZh3a5rtwud81QSIzjowhbdH8c2Jk8gz/ 0DJuAg3Tm2Yf7PTTQn84WzJWTa0VaTJ4UbvWvMLLW0J37bF7r7RO3Ho+AzrS3mz+0eOi CDrA== MIME-Version: 1.0 X-Received: by 10.152.105.17 with SMTP id gi17mr11063177lab.46.1359725426055; Fri, 01 Feb 2013 05:30:26 -0800 (PST) Received: by 10.152.109.204 with HTTP; Fri, 1 Feb 2013 05:30:26 -0800 (PST) In-Reply-To: <084F8A1FB98040A1BD1B987D3CF3D518@gmail.com> References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> <510ba796.09df0e0a.3a70.fffff0f4SMTPIN_ADDED_BROKEN@mx.google.com> <084F8A1FB98040A1BD1B987D3CF3D518@gmail.com> Date: Fri, 1 Feb 2013 08:30:26 -0500 Message-ID: Subject: Re: NEW RELATION: action From: Darrel Miller To: link-relations Content-Type: multipart/alternative; boundary=f46d040892fd03198b04d4a9bf5a X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: darrel@tavis.ca List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 13:30:28 -0000 --f46d040892fd03198b04d4a9bf5a Content-Type: text/plain; charset=ISO-8859-1 Ioseb, On Fri, Feb 1, 2013 at 6:42 AM, Ioseb Dzmanashvili < ioseb.dzmanashvili@gmail.com> wrote: > Draft doesn't mention anything about GET request to "action" links for the > moment, though i think service implementors can use: 3xx status codes to > redirect user agent somewhere else, return 4xx(405 Method Not Allowed for > example) etc.... But the action must be performed only if client sends POST > request. > > I would be tempted to just use the GET as a placeholder for documentation on what the POST does. Darrel --f46d040892fd03198b04d4a9bf5a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Ioseb,

On Fri, Feb 1, 2013 at 6:42 AM, Ioseb Dzmanashvili <ioseb.dzmanashvili@gmail.com> wrote:
Draft doesn't mention anything about GET request t= o "action" links for the moment, though i think service implement= ors can use: 3xx status codes to redirect user agent somewhere else, return= 4xx(405 Method Not Allowed for example) etc.... But the action must be per= formed only if client sends POST request.


I would be temp= ted to just use the GET as a placeholder for documentation on what the POST= does.

Darrel=A0
--f46d040892fd03198b04d4a9bf5a-- From markus.lanthaler@gmx.net Fri Feb 1 05:53:06 2013 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 3D17021F8EEB for ; Fri, 1 Feb 2013 05:53:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.85 X-Spam-Level: X-Spam-Status: No, score=-0.85 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] 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 4e6BbYE5Liub for ; Fri, 1 Feb 2013 05:53:05 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9AAA921F8F6C for ; Fri, 1 Feb 2013 05:52:43 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.27]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MRydg-1UOsj22H0s-00TBTf for ; Fri, 01 Feb 2013 14:52:42 +0100 Received: (qmail invoked by alias); 01 Feb 2013 13:52:42 -0000 Received: from 84-115-182-43.dynamic.surfer.at (EHLO Vostro3500) [84.115.182.43] by mail.gmx.net (mp027) with SMTP; 01 Feb 2013 14:52:42 +0100 X-Authenticated: #419883 X-Provags-ID: V01U2FsdGVkX1+37k9qEeC3lmBqkwzcpzeudWDVxPWk9qH7Fmrjg5 JUMcjc3jwYJSWN From: "Markus Lanthaler" To: References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> <-3128426172162859719@unknownmsgid> In-Reply-To: Subject: RE: NEW RELATION: action Date: Fri, 1 Feb 2013 14:52:36 +0100 Message-ID: <01fa01ce0083$65105cd0$2f311670$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4Af7uv3VOW9bliQ76RF/CXlVgEqwAA37RA Content-Language: de 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: Fri, 01 Feb 2013 13:53:06 -0000 On Friday, February 01, 2013 2:26 PM, Darrel Miller wrote: > It isn't different. It allows that same functionality to be embedded in any > hypermedia type, Or even just in link headers. I think the fact that you > can do it in HTML further validates this proposal. Hmm.. the reason I do not particularly like it is because it basically means nothing. It's basically that same as "accepts-post", and POST has no semantics at all. It "works" in HTML because there's a human reading and interpreting the text. If you would be going to use that in machine-to-machine communication you would either need to infer the meaning from the target URL (which you shouldn't because they are opaque) or use something else (a title, a second rel, etc.) to convey the meaning. AFAICS, you cannot do anything useful with just rel="action". P.S.: Darrel, you replied just to me -- Markus Lanthaler @markuslanthaler From ioseb.dzmanashvili@gmail.com Fri Feb 1 06:53:57 2013 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 88B4421F8C99 for ; Fri, 1 Feb 2013 06:53:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_46=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 NMANVjeFQIwe for ; Fri, 1 Feb 2013 06:53:56 -0800 (PST) Received: from mail-ee0-f41.google.com (mail-ee0-f41.google.com [74.125.83.41]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6F921E803A for ; Fri, 1 Feb 2013 06:53:56 -0800 (PST) Received: by mail-ee0-f41.google.com with SMTP id c13so2173476eek.28 for ; Fri, 01 Feb 2013 06:53:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:message-id:in-reply-to:references :subject:x-mailer:mime-version:content-type; bh=BIWfjmQrn7eMV5aHcrQieZnyTAmubgRCEq+kS/avxcc=; b=MWzGIgRkQGLXg4P9nRj1UzcLNBOmsNyg7IiOCfgMs6yrPhOrchOVJWsp91z105LFF7 FYyiWA51owh+UBAWPiOQdaeUMmbM8mztQc5toHQkmaxUjxEmPcdjmisLCQHQPZd/zZvl yAxeAVHf8CddXOXhMTegx1IYWg9rVAmq8ZR9HWO7hRsJvDlDSV4FMdYCzPWKvvcE7iLj E9BNSXICJF9sozSFNEBfxOb2PRigdeEVsY/2Jl3ZFmO0XCf0dWrMvMcDW00ymvXhFwGr zpQODAuKXwP+3geRna4e77qNjCcRyuikNkhB0rQTQ5CirHBBM0IOqH/jIG1fgqnrw+GX 3Vgw== X-Received: by 10.14.203.131 with SMTP id f3mr10765830eeo.1.1359730435291; Fri, 01 Feb 2013 06:53:55 -0800 (PST) Received: from [10.131.33.116] ([213.131.60.234]) by mx.google.com with ESMTPS id 3sm12894329eej.6.2013.02.01.06.53.52 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 01 Feb 2013 06:53:53 -0800 (PST) Date: Fri, 1 Feb 2013 18:53:52 +0400 From: Ioseb Dzmanashvili To: mca Message-ID: <53BB611AF85E427E9575A19C12E166BA@gmail.com> In-Reply-To: References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> Subject: Re: NEW RELATION: action X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="510bd700_29d0a5df_28a" 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: Fri, 01 Feb 2013 14:53:57 -0000 --510bd700_29d0a5df_28a Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Mike, Thanks for feedback! > 1) "action" will always be unsafe, but MAY be either idempotent (PUT/DELETE) or non-idempotent (PATCH/POST). This is a problem. Either a) establish it as one or the other or, b) create two relations to handle each case. Regarding idempotency i do not have clear use cases right now(some examples would be great here), hence no idea what second link relation type should be. Establishing the "action" as unsafe looks more appropriate for me at the moment. > 2) since "action" will always be unsafe, it MUST NOT be applied to elements already defined as "safe" by the media type (HTML.A, HTML.LINK, HTML.IFRAME, HTML.IMG, HTML.FORM@method="get", etc.). Wording should be added that makes this clear. Accepted! Cheers, ioseb On Friday, February 1, 2013 at 5:36 PM, mca wrote: > My initial comments are: > > 1) "action" will always be unsafe, but MAY be either idempotent (PUT/DELETE) or non-idempotent (PATCH/POST). This is a problem. Either a) establish it as one or the other or, b) create two relations to handle each case. > > 2) since "action" will always be unsafe, it MUST NOT be applied to elements already defined as "safe" by the media type (HTML.A, HTML.LINK, HTML.IFRAME, HTML.IMG, HTML.FORM@method="get", etc.). Wording should be added that makes this clear. > > > > mca > +1.859.757.1449 > skype: mca.amundsen > http://amundsen.com/blog/ > http://twitter.com/mamund > https://github.com/mamund > http://www.linkedin.com/in/mikeamundsen > > > > On Thu, Jan 31, 2013 at 2:10 PM, Ioseb Dzmanashvili wrote: > > Dear All, > > > > I've submitted new draft of the 'create' link relation type: http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-00 > > > > Description: > > - The link relation is intentionally generic, and it can be used with multiple media types in a wide variety of use cases. > > - When included in a resource which represents a collection, the 'form' link relation identifies a target resource that represents the form for adding a new member to the context collection. > > - The target IRI points to a resource that is responsible to perform an action that may affect state of the context resource or > > initiate process. > > > > Could you please review? > > Thanks in advance! > > > > Best regards, > > ioseb > > > > -- > > Ioseb Dzmanashvili > > AzRy LLC > > Software Architect > > #8, Chachava str. > > Tbilisi, 0159, Georgia > > > > Mobile: +(995) 99753388 > > github.com/ioseb (http://github.com/ioseb) > > pecl.php.net/user/ioseb (http://pecl.php.net/user/ioseb) > > twitter.com/iosebi (http://twitter.com/iosebi) > > > > > > > > _______________________________________________ > > link-relations mailing list > > link-relations@ietf.org (mailto:link-relations@ietf.org) > > https://www.ietf.org/mailman/listinfo/link-relations > > > --510bd700_29d0a5df_28a Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Mike, 

Thanks for f= eedback=21

> 1) =22action=22 will always= be unsafe, but MAY be either idempotent (PUT/DELETE) or non-idempotent (= PATCH/POST). This is a problem. Either a) establish it as one or the othe= r or, b) create two relations to handle each case.

Regarding idempotency i do not have clear use cases right now(some exa= mples would be great here), hence no idea what second link relation type = should be. Establishing the =22action=22 as unsafe looks more appropriate= for me at the moment. 

> 2) since = =22action=22 will always be unsafe, it MUST NOT be applied to elements al= ready defined as =22safe=22 by the media type (HTML.A, HTML.LINK, HTML.I=46= RAME, HTML.IMG, HTML.=46ORM=40method=3D=22get=22, etc.). Wording should b= e added that makes this clear.

Accepted=21
=

Cheers,
ioseb
=20

On =46riday, =46ebruar= y 1, 2013 at 5:36 PM, mca wrote:

My initial comments are:

1) =22action=22 will always be unsafe, but MAY be either idempoten= t (PUT/DELETE) or non-idempotent (PATCH/POST). This is a problem. Either = a) establish it as one or the other or, b) create two relations to handle= each case.

2) since =22action=22 will always be unsafe, it MUST = NOT be applied to elements already defined as =22safe=22 by the media typ= e (HTML.A, HTML.LINK, HTML.I=46RAME, HTML.IMG, HTML.=46ORM=40method=3D=22= get=22, etc.). Wording should be added that makes this clear.





On Thu, Jan 31, 2013 at 2:10 PM, Ioseb Dzmanashvili <ioseb.dzmanashvili=40gmail.com> wrot= e:
Dear All,

I've submitte= d new draft of the 'create' link relation type: http://tools.ietf.org/html/draft-ioseb-dzmanashvili-act= ion-link-relation-00

Description:
- The link relation is intenti= onally generic, and it can be used with  multiple media types in a w= ide variety of use cases.
- When included in a resource which r= epresents a collection, the 'form'  link relation identifies a targe= t resource that represents the form for adding a new member to the contex= t collection.
- The target IRI points to a resource that is responsible to perform= an action that may affect state of the context resource or
&nb= sp;initiate process.

Could you please review=3F<= /div>
Thanks in advance=21

Best regards,
ios= eb
-- 
Ioseb Dzmanashvili
AzRy LLC
Software Archi= tect
=238, Chachava str.
Tbilisi, 0159, Georgia
Mobile: +(995) 99753388

=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 mailing list
link-relations=40ietf.or= g
https://www.ietf.org/mailman/listinfo/link-relations<= /a>


=20 =20 =20 =20
=20

--510bd700_29d0a5df_28a-- From ioseb.dzmanashvili@gmail.com Fri Feb 1 07:16:31 2013 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 18B1121E8030 for ; Fri, 1 Feb 2013 07:16:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_46=0.6, J_CHICKENPOX_72=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 RDRiIV4ARCmU for ; Fri, 1 Feb 2013 07:16:30 -0800 (PST) Received: from mail-ee0-f47.google.com (mail-ee0-f47.google.com [74.125.83.47]) by ietfa.amsl.com (Postfix) with ESMTP id 9C26D11E8099 for ; Fri, 1 Feb 2013 07:16:29 -0800 (PST) Received: by mail-ee0-f47.google.com with SMTP id e52so2107024eek.20 for ; Fri, 01 Feb 2013 07:16:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:message-id:in-reply-to:references :subject:x-mailer:mime-version:content-type; bh=isarksgG2r3FVNQRWqpM8DcGVYAWp17zIk+zGE6Uzk0=; b=IOTHReuQZWclHS61S2Mn0RYa00+6HFhLhJFw02EBEy63b9rJLZcbf670U9vywGduSm NDuralva0BEwmK7GJlmmIY2sHmagF7uTsH9g08oGsdZAAEpbfjiyAsMpppDNGm3CV5w/ zP5HrBffXG8B6bthPkGPksL5uB+OEy053yI1gIsuh+aTi+go7NNJbF/CNaI6LcwvGIWW 9Ib/flC+9zpaTJzpk/NCEf1+bUPkIdGXCODWA2kY+MO3c2xY6VOUTzKj45uHa8i6YQ+M HuZnI6vk+uUKPlvh2ZOCm/lv5tp+l85MDtYPqZT2AmhEowhUxGXOQYjLj1WR8uC+k1um 0d0g== X-Received: by 10.14.173.196 with SMTP id v44mr39927273eel.29.1359731788827; Fri, 01 Feb 2013 07:16:28 -0800 (PST) Received: from [10.131.33.116] ([213.131.60.234]) by mx.google.com with ESMTPS id 46sm12990550eeg.4.2013.02.01.07.16.25 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 01 Feb 2013 07:16:27 -0800 (PST) Date: Fri, 1 Feb 2013 19:16:26 +0400 From: Ioseb Dzmanashvili To: Markus Lanthaler Message-ID: <9090DD8D497247E7BD1C3FE30231A0CC@gmail.com> In-Reply-To: <084F8A1FB98040A1BD1B987D3CF3D518@gmail.com> References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> <510ba796.09df0e0a.3a70.fffff0f4SMTPIN_ADDED_BROKEN@mx.google.com> <084F8A1FB98040A1BD1B987D3CF3D518@gmail.com> Subject: Re: NEW RELATION: action X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="510bdc4a_20d7b9b5_28a" Cc: darrel@tavis.ca, mca , 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: Fri, 01 Feb 2013 15:16:31 -0000 --510bdc4a_20d7b9b5_28a Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline I'm guessing something went wrong with email thread. I see some messages in mail list which missed my mailbox and do not see @mamund's email message at all. I'm including combined conversation in this email: > Ioseb Dzmanashvili wrote: > > Hi Mike, > > Thanks for feedback! > > > 1) "action" will always be unsafe, but MAY be either idempotent (PUT/DELETE) or non-idempotent (PATCH/POST). This is a problem. Either a) establish it as one or the other or, b) create two relations to handle each case. > > Regarding idempotency i do not have clear use cases right now(some examples would be great here), hence no idea what second link relation type should be. Establishing the "action" as unsafe looks more appropriate for me at the moment. > > > 2) since "action" will always be unsafe, it MUST NOT be applied to elements already defined as "safe" by the media type (HTML.A, HTML.LINK, HTML.IFRAME, HTML.IMG, HTML.FORM@method="get", etc.). Wording should be added that makes this clear. > > Accepted! > > Cheers, > ioseb > > > > Mike Amundsen wrote: > > > > My initial comments are: > > > > 1) "action" will always be unsafe, but MAY be either idempotent (PUT/DELETE) or non-idempotent (PATCH/POST). This is a problem. Either a) establish it as one or the other or, b) create two relations to handle each case. > > > > 2) since "action" will always be unsafe, it MUST NOT be applied to elements already defined as "safe" by the media type (HTML.A, HTML.LINK, HTML.IFRAME, HTML.IMG, HTML.FORM@method="get", etc.). Wording should be added that makes this clear. > > > > mca > > > On Friday, February 01, 2013 2:26 PM, Darrel Miller wrote: > > > > > > > It isn't different. It allows that same functionality to be embedded in > > > any > > > > hypermedia type, Or even just in link headers. I think the fact that you > > > > can do it in HTML further validates this proposal. > > > > > > Hmm.. the reason I do not particularly like it is because it basically means > > > nothing. It's basically that same as "accepts-post", and POST has no > > > semantics at all. It "works" in HTML because there's a human reading and > > > interpreting the text. If you would be going to use that in > > > machine-to-machine communication you would either need to infer the meaning > > > from the target URL (which you shouldn't because they are opaque) or use > > > something else (a title, a second rel, etc.) to convey the meaning. AFAICS, > > > you cannot do anything useful with just rel="action". > > > > > > > > > P.S.: Darrel, you replied just to me > > > > > > -- > > > Markus Lanthaler > > > @markuslanthaler > > > > > > > Ioseb, > > > > > > > > > On Fri, Feb 1, 2013 at 6:42 AM, Ioseb Dzmanashvili wrote: > > > > > Draft doesn't mention anything about GET request to "action" links for the moment, though i think service implementors can use: 3xx status codes to redirect user agent somewhere else, return 4xx(405 Method Not Allowed for example) etc.... But the action must be performed only if client sends POST request. > > > > > > > > > > > > > I would be tempted to just use the GET as a placeholder for documentation on what the POST does. > > > > > > > > Darrel > > > > > Markus, > > > > > > > > > > > > > > > On Fri, Feb 1, 2013 at 6:31 AM, Markus Lanthaler wrote: > > > > > > > > > > Talking about HTML, how is that different from using an empty form (just submit button) and @method=POST? > > > > > > > > > > > > > > > It isn't different. It allows that same functionality to be embedded in any hypermedia type, Or even just in link headers. I think the fact that you can do it in HTML further validates this proposal. > > > > > > > > > > Darrel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > cheers, ioseb On Friday, February 1, 2013 at 3:42 PM, Ioseb Dzmanashvili wrote: > Hi Markus, > > Draft doesn't mention anything about GET request to "action" links for the moment, though i think service implementors can use: 3xx status codes to redirect user agent somewhere else, return 4xx(405 Method Not Allowed for example) etc.... But the action must be performed only if client sends POST request. > > P.S. > i truly believe that such links must not be exposed to public unless client doesn't have enough permissions. > > Cheers, > ioseb > > On Friday, February 1, 2013 at 3:31 PM, Markus Lanthaler wrote: > > > On Friday, February 01, 2013 10:45 AM, Ioseb Dzmanashvili wrote: > > > > > > To me this smells a lot like a (REST-) anti pattern. > > > > > > I do not agree. Which REST constraint is violated in this case? > > > Using POST without body is valid and "action" links expose > > > availability of actions which may be performed: > > > > > > * without knowing media type; > > > * without need to construct whole message(to conform PUT's > > > replace semantics); > > > * no need to use PATCH > > > * "action" links can be filtered by client and displayed to > > > user(and here we do not even need additional link relation > > > extensions) > > > > > > > > > The problem is they can just be filtered by clients who know about them. How would a generic crawler know it has to avoid those action links? For example, looking at your example: > > > > > > < HTTP/1.1 200 OK > > < Content-Type: ... > > < Content-Length: ... > > < Link: ; rel="action urn:restart"; title="Restart" > > > > Imagine that the link would be embedded in a HTML page: > > > > Restart > > > > What would happen if a crawler follows that link? Would the service be restarted? Assuming that you say links with this relation type just accept POST (and I think that's what Jan was concerned about because it wasn't clear in your initial mail), would it result in an error because it uses GET? > > > > > > On Friday, February 1, 2013 at 4:31 AM, Darrel Miller wrote: > > > > > Yes there are other ways of doing this, but I can't see any > > > negative impacts on the system by using this approach. > > > > > > [..] > > > > > > The huge benefit in my mind of this link relation is that it > > > opens the door for generic clients to be able to start doing > > > some simple write operations. > > > > > > > > > Talking about HTML, how is that different from using an empty form (just submit button) and @method=POST? > > > > > > > > > > -- > > Markus Lanthaler > > @markuslanthaler > > > > > > > > > > --510bdc4a_20d7b9b5_28a Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
I'm guessing something went wrong with email thread.= I see some messages in mail list which missed my mailbox and do not see = =40mamund's email message at all. I'm including combined conversation in = this email:

<= div>Ioseb Dzmanashvili wrote:

Hi Mike, 

Thanks for feedback=21

>= ; 1) =22action=22 will always be unsafe, but MAY be either idempotent (PU= T/DELETE) or non-idempotent (PATCH/POST). This is a problem. Either a) es= tablish it as one or the other or, b) create two relations to handle each= case.

Regarding idempotency i do not have clear= use cases right now(some examples would be great here), hence no idea wh= at second link relation type should be. Establishing the =22action=22 as = unsafe looks more appropriate for me at the moment. 

<= /div>
> 2) since =22action=22 will always be unsafe, it MUST NOT b= e applied to elements already defined as =22safe=22 by the media type (HT= ML.A, HTML.LINK, HTML.I=46RAME, HTML.IMG, HTML.=46ORM=40method=3D=22get=22= , etc.). Wording should be added that makes this clear.

Accepted=21

Cheers,
ioseb

Mike Amunds= en wrote:

My initial comments are:

1) =22action=22 will always be unsafe, but MAY be either idempotent= (PUT/DELETE) or non-idempotent (PATCH/POST). This is a problem. Either a= ) establish it as one or the other or, b) create two relations to handle = each case.

2) since =22action=22 will always be = unsafe, it MUST NOT be applied to elements already defined as =22safe=22 = by the media type (HTML.A, HTML.LINK, HTML.I=46RAME, HTML.IMG, HTML.=46OR= M=40method=3D=22get=22, etc.). Wording should be added that makes this cl= ear.

mca
On =46riday, =46ebruary 01, 2013 2:26 PM, Darrel Miller w= rote:

> It isn't different.  It allows t= hat same functionality to be embedded in
any
> hyp= ermedia type, Or even just in link headers.  I think the fact that y= ou
> can do it in HTML further validates this proposal.

Hmm.. the reason I do not particularly like it is be= cause it basically means
nothing. It's basically that same as =22= accepts-post=22, and POST has no
semantics at all. It =22works=22= in HTML because there's a human reading and
interpreting the t= ext. If you would be going to use that in
machine-to-machine co= mmunication you would either need to infer the meaning
from the= target URL (which you shouldn't because they are opaque) or use
something else (a title, a second rel, etc.) to convey the meaning. A=46= AICS,
you cannot do anything useful with just rel=3D=22action=22= .


P.S.: Darrel, you replied just = to me

--
Markus Lanthaler
=40= markuslanthaler
I= oseb,

On =46r= i, =46eb 1, 2013 at 6:42 AM, Ioseb Dzmanashvili <ioseb.dzmanashvili at= gmail.com> wrote:
Draf= t doesn't mention anything about GET request to =22action=22 links for th= e moment, though i think service implementors can use: 3xx status codes t= o redirect user agent somewhere else, return 4xx(405 Method Not Allowed f= or example) etc.... But the action must be performed only if client sends= POST request.
I would be tempted to just us= e the GET as a placeholder for documentation on what the POST does.
=

Darrel
=
Markus,


On =46ri, =46eb= 1, 2013 at 6:31 AM, Markus Lanthaler <markus.lanthaler at gmx.net> wrote:

Talking= about HTML, how is that different from using an empty form (just submit = button) and =40method=3DPOST=3F


I= t isn't different.  It allows that same functionality to be embedded= in any hypermedia type, Or even just in link headers.  I think the = fact that you can do it in HTML further validates this proposal.

Darrel
=
<= /div>

cheers,
ioseb
=20

On =46riday, =46ebruar= y 1, 2013 at 3:42 PM, Ioseb Dzmanashvili wrote:

Hi Markus, 

Draft does= n't mention anything about GET request to =22action=22 links for the mome= nt, though i think service implementors can use: 3xx status codes to redi= rect user agent somewhere else, return 4xx(405 Method Not Allowed for exa= mple) etc.... But the action must be performed only if client sends POST = request.

P.S.
i truly believe that suc= h links must not be exposed to public unless client doesn't have enough p= ermissions. 

Cheers,
ioseb <= /div> =20

On =46riday, =46ebruar= y 1, 2013 at 3:31 PM, Markus Lanthaler wrote:

On =46riday, =46ebruary 01, 2013= 10:45 AM, Ioseb Dzmanashvili wrote:

To me this smells a= lot like a (REST-) anti pattern.

I= do not agree. Which REST constraint is violated in this case=3F
Using POST without body is valid and =22action=22 links expose
availability of actions which may be performed:

* without knowing media type;
* without need to construct wh= ole message(to conform PUT's
replace semantics);
* = no need to use PATCH
* =22action=22 links can be filtered by c= lient and displayed to
user(and here we do not even need additi= onal link relation
extensions)
The problem is they can just be filtered by clients who know = about them. How would a generic crawler know it has to avoid those action= links=3F =46or example, looking at your example:


< HTTP/1.1 200 OK
< Content-Type: ...
< Content-Length: ...
< Link: </service/manage= r>; rel=3D=22action urn:restart=22; title=3D=22Restart=22
Imagine that the link would be embedded in a HTML page:

<a href=3D=22/service/manager=22 rel=3D=22action = urn:restart=22>Restart</a>

What would h= appen if a crawler follows that link=3F Would the service be restarted=3F= Assuming that you say links with this relation type just accept POST (an= d I think that's what Jan was concerned about because it wasn't clear in = your initial mail), would it result in an error because it uses GET=3F


On =46riday, =46ebruary 1, 2013 at = 4:31 AM, Darrel Miller wrote:

Yes there are other ways of doing this, but I can't see = any
negative impacts on the system by using this approach.

=5B..=5D

The huge benefit i= n my mind of this link relation is that it
opens the door for g= eneric clients to be able to start doing
some simple write oper= ations.

Talking about HTML= , how is that different from using an empty form (just submit button) and= =40method=3DPOST=3F




--
Markus Lanthaler
=40markuslantha= ler
=20 =20 =20 =20

--510bdc4a_20d7b9b5_28a-- From ioseb.dzmanashvili@gmail.com Fri Feb 1 07:46:43 2013 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 1C19C21F8E1D for ; Fri, 1 Feb 2013 07:46:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, J_CHICKENPOX_46=0.6, J_CHICKENPOX_52=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 Prg8H1DnYdwk for ; Fri, 1 Feb 2013 07:46:42 -0800 (PST) Received: from mail-ea0-f177.google.com (mail-ea0-f177.google.com [209.85.215.177]) by ietfa.amsl.com (Postfix) with ESMTP id 1185F21F8E1B for ; Fri, 1 Feb 2013 07:46:41 -0800 (PST) Received: by mail-ea0-f177.google.com with SMTP id n13so1741580eaa.22 for ; Fri, 01 Feb 2013 07:46:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:message-id:in-reply-to:references :subject:x-mailer:mime-version:content-type; bh=eTb4DjRLfe0YL1GKPC+b687tYW0ASCxjHoP2KeHTbEs=; b=R98g2FD+N1pKjCS104RRh82bNVrqpozipsycxdlDgiR9yW5/snLWeHxYacOEAF1ioE 72Sp3dUvpNsUHehxmxGPYzjZTPwLapQ7IYoADDH2ZkMZnBTZd4XPaiBgJkcmXwAkyRIg B+fb7gviVvbIoJnKfVhq2EE9963g+3uaz45j1vi/qSub4ZhY7jwgG1GWX5CXTlkpeLGe Fe8TkdfDyvGQKffFylavVHWfgk0HA1dTYCyOx3W00zdsaP/n0Tu5uyAjXL8RXqINnTdP Cjn+1SyqHBA1t4m0tBSsQDAtzjAJoc+JF2K8IwPkS5WXiDj/50y270hWjAkg+lv0X02N ZS7A== X-Received: by 10.14.2.196 with SMTP id 44mr40582131eef.25.1359733601246; Fri, 01 Feb 2013 07:46:41 -0800 (PST) Received: from [10.131.33.116] ([213.131.60.234]) by mx.google.com with ESMTPS id f6sm13103249eeo.7.2013.02.01.07.46.38 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 01 Feb 2013 07:46:39 -0800 (PST) Date: Fri, 1 Feb 2013 19:46:39 +0400 From: Ioseb Dzmanashvili To: Markus Lanthaler Message-ID: In-Reply-To: <9090DD8D497247E7BD1C3FE30231A0CC@gmail.com> References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> <510ba796.09df0e0a.3a70.fffff0f4SMTPIN_ADDED_BROKEN@mx.google.com> <084F8A1FB98040A1BD1B987D3CF3D518@gmail.com> <9090DD8D497247E7BD1C3FE30231A0CC@gmail.com> Subject: Re: NEW RELATION: action X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="510be35f_7547b1d6_28a" Cc: darrel@tavis.ca, mca , 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: Fri, 01 Feb 2013 15:46:43 -0000 --510be35f_7547b1d6_28a Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear all, >From previous messages questions raised regarding GET request, below are comments from @Mike and @Darrel. @Mike Amundsen's comment: > 2) since "action" will always be unsafe, it MUST NOT be applied to elements already defined as "safe" by the media type (HTML.A, HTML.LINK, HTML.IFRAME, HTML.IMG, HTML.FORM@method="get", etc.). Wording should be added that makes this clear. @Darrel Miller's comment: > I would be tempted to just use the GET as a placeholder for documentation on what the POST does. ---------------------------------------- @Markus > Hmm.. the reason I do not particularly like it is because it basically means > nothing. It's basically that same as "accepts-post", and POST has no semantics at all. Draft defines semantics and its very different. It implies that accepting resource can affect state of the context resource or initiate some process in contrast to POST which may mean anything. Additionally it creates possibility to attach multiple "action" links to a particular resource that may or be rendered for users(or used in M2M communication if additional semantics are defined) and consuming agent doesn't need to assume or guess anything. > It "works" in HTML because there's a human reading and interpreting the text. Not only in HTML. This will work in any application which involves human interaction. > If you would be going to use that in machine-to-machine communication you would either need to infer the meaning > from the target URL (which you shouldn't because they are opaque) or use > something else (a title, a second rel, etc.) to convey the meaning. There is no need to to infer something from the target URI or use something else. Draft states that: "Actual function to be performed by the server, MAY be advertised by including an extension link relation types as defined per Section 4.2 of [RFC5988]." which is perfectly valid approach especially when there is need for M2M interaction. I do not get what is wrong with second rel? There are bunch of link relations which doesn't add any value to M2M interaction unless participant(s) are trained correspondingly. > AFAICS, you cannot do anything useful with just rel="action". I do not agree. a) The relation works perfectly in applications where user interaction exists and there is no need for defining additional semantics; and b) as i noted above spec clearly says how to extend it's meaning. Best regards, ioseb On Friday, February 1, 2013 at 7:16 PM, Ioseb Dzmanashvili wrote: > > > > Markus > > > > > > > > > > > > > > > > > > > > > --510be35f_7547b1d6_28a Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Dear all,

=46rom previ= ous messages questions raised regarding GET request, below are comments f= rom =40Mike and =40Darrel.

=40Mike Amundsen's co= mment:
> 2) since =22action=22 will always be unsafe, it MUS= T NOT be applied to elements already defined as =22safe=22 by the media t= ype (HTML.A, HTML.LINK, HTML.I=46RAME, HTML.IMG, HTML.=46ORM=40method=3D=22= get=22, etc.). Wording should be added that makes this clear.
<= br>
=40Darrel Miller's comment: 
> I would be= tempted to just use the GET as a placeholder for documentation on what t= he POST does. 

----------------------------= ------------

=40Markus
> Hmm.. the = reason I do not particularly like it is because it basically means
<= div>> nothing. It's basically that same as =22accepts-post=22, and POS= T has no semantics at all. 

Draft defines s= emantics and its very different. It implies that accepting resource can a= ffect state of the context resource or initiate some process in contrast = to POST which may mean anything. Additionally it creates possibility to a= ttach multiple =22action=22 links to a particular resource that may or be= rendered for users(or used in M2M communication if additional semantics = are defined) and consuming agent doesn't need to assume or guess anything= . 

> It =22works=22 in HTML because ther= e's a human reading and interpreting the text.

N= ot only in HTML. This will work in any application which involves human i= nteraction. 

> If you would be going to = use that in machine-to-machine communication you would either need to inf= er the meaning
> from the target URL (which you shouldn't be= cause they are opaque) or use
> something else (a title, a s= econd rel, etc.) to convey the meaning.

There is= no need to to infer something from the target URI or use something else.= Draft states that: =22Actual function to be performed by the server, MAY= be advertised by including an extension link relation types as defined p= er Section 4.2 of =5BR=46C5988=5D.=22 which is perfectly valid approach e= specially when there is need for M2M interaction. I do not get what is wr= ong with second rel=3F There are bunch of link relations which doesn't ad= d any value to M2M interaction unless participant(s) are trained correspo= ndingly.

> A=46AICS, you cannot do anything u= seful with just rel=3D=22action=22.

I do not agr= ee. a) The relation works perfectly in applications where user interactio= n exists and there is no need for defining additional semantics; and b) a= s i noted above spec clearly says how to extend it's meaning.
<= br>
Best regards,
ioseb

=20

On =46riday, =46ebruar= y 1, 2013 at 7:16 PM, Ioseb Dzmanashvili wrote:

=
Markus
 =20 =20 =20 =20
=20

--510be35f_7547b1d6_28a-- From markus.lanthaler@gmx.net Fri Feb 1 08:11:07 2013 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 760E521E804C for ; Fri, 1 Feb 2013 08:11:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.95 X-Spam-Level: X-Spam-Status: No, score=-0.95 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] 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 bBImtuwKJUud for ; Fri, 1 Feb 2013 08:11:07 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7FD21E8044 for ; Fri, 1 Feb 2013 08:11:06 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.35]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0M6yV9-1Ux9362z3t-00wjCl for ; Fri, 01 Feb 2013 17:11:05 +0100 Received: (qmail invoked by alias); 01 Feb 2013 16:11:05 -0000 Received: from 84-115-182-43.dynamic.surfer.at (EHLO Vostro3500) [84.115.182.43] by mail.gmx.net (mp035) with SMTP; 01 Feb 2013 17:11:05 +0100 X-Authenticated: #419883 X-Provags-ID: V01U2FsdGVkX1/TJO9WjFLTBBDCtaKrTD5b48krdDyFklO4IE46hy +j1DU81yLFh2hk From: "Markus Lanthaler" To: "'Ioseb Dzmanashvili'" References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> <510ba796.09df0e0a.3a70.fffff0f4SMTPIN_ADDED_BROKEN@mx.google.com> <084F8A1FB98040A1BD1B987D3CF3D518@gmail.com> <9090DD8D497247E7BD1C3FE30231A0CC@gmail.com> In-Reply-To: Subject: RE: NEW RELATION: action Date: Fri, 1 Feb 2013 17:10:58 +0100 Message-ID: <025b01ce0096$ba1ab550$2e501ff0$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4Ak1QDfoc27+AhSqyzgqSXvgu1HwAAO86g Content-Language: de X-Y-GMX-Trusted: 0 Cc: darrel@tavis.ca, 'mca' , 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: Fri, 01 Feb 2013 16:11:07 -0000 On Friday, February 01, 2013 4:47 PM , Ioseb Dzmanashvili wrote: > There is no need to to infer something from the target URI or use = something else. > Draft states that: "Actual function to be performed by the server, MAY = be > advertised by including an extension link relation types as defined = per Section 4.2 > of [RFC5988]." MAY means that it's not required. If it's not required, what does such a = link mean if there isn't any other information? > I do not get what is wrong with second rel? There are bunch of link = relations > which doesn't add any value to M2M interaction unless participant(s) = are > trained correspondingly. There's nothing wrong with a second rel. It's also true that consumers = need to recognize the token to do something useful. The problem is that = the "action" rel just says, you can POST to this URL, if you do so, you = SHOULD not include a body in your POST. > > AFAICS, you cannot do anything useful with just rel=3D"action". > > I do not agree. a) The relation works perfectly in applications > where user interaction exists and there is no need for defining > additional semantics; > and b) as i noted above spec clearly says how to extend it's > meaning. So, in a user facing app, what does this mean: OK? What I'm trying to say is, that basically all the information is in the = "OK" (well, in this case it isn't) and not in "action". Maybe it's also = just that action is irritating me. I definitely find it too generic and = overloaded. Perhaps something like "ping" (which itself is also quite = overloaded) might work better. Just an idea. -- Markus Lanthaler @markuslanthaler From mca@amundsen.com Fri Feb 1 05:37:01 2013 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 493B121F8F15 for ; Fri, 1 Feb 2013 05:37:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.177 X-Spam-Level: X-Spam-Status: No, score=-0.177 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_46=0.6, NO_RELAYS=-0.001] 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 i6zQlCu0kNtM for ; Fri, 1 Feb 2013 05:36:59 -0800 (PST) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id E9EBC21F8F17 for ; Fri, 1 Feb 2013 05:36:52 -0800 (PST) Received: by mail-we0-f182.google.com with SMTP id t57so3029332wey.13 for ; Fri, 01 Feb 2013 05:36:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=5MH9XKa5JxsnROYer9mOf/uZXvXjHdyVqA+Tgfa8IOc=; b=ej436gXjFXUiNgyhjqyKOE1Nm8jrOyOCHbFeHCjshb0rgqEoffbDlONlv0RLW+kAjT Yu0n0m+LM+y8aa+EW2xVNGyKPl560t0U+CKwKtvW+LQXKoTq2zeMWVaRftb26nO7ifDx zw8ggiZAkLBteMArxjWAwqnUUcBtxuMLe+QuD/rIwAHz5x06KD+ebC9JDKkfH1ukNiWJ nQv6bZymS5y5KyhottZKfI4gbCJF6UpZ220ZVClvgiLk1ugrW58ORP6BF3KVWUdK7PPs Rlkei7A1iwWYuRX/VH+n0WbdEPifpxDFdchdaHOilTbwsJi2nzTixIXyOwgq9j6FhbT3 tlMw== X-Received: by 10.194.76.237 with SMTP id n13mr21883725wjw.57.1359725811979; Fri, 01 Feb 2013 05:36:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.166.36 with HTTP; Fri, 1 Feb 2013 05:36:30 -0800 (PST) In-Reply-To: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> From: mca Date: Fri, 1 Feb 2013 08:36:30 -0500 Message-ID: Subject: Re: NEW RELATION: action To: Ioseb Dzmanashvili Content-Type: multipart/alternative; boundary=047d7bfcef7403d52404d4a9d625 X-Gm-Message-State: ALoCoQkCOIX0/InJNxsb2j7Skt/QDrGzHPT8G2L4E7D5eVT3UQ1sgT631JeLGaj1zRoyb6OGmD26 X-Mailman-Approved-At: Fri, 01 Feb 2013 08:22:02 -0800 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: Fri, 01 Feb 2013 13:37:01 -0000 --047d7bfcef7403d52404d4a9d625 Content-Type: text/plain; charset=ISO-8859-1 My initial comments are: 1) "action" will always be unsafe, but MAY be either idempotent (PUT/DELETE) or non-idempotent (PATCH/POST). This is a problem. Either a) establish it as one or the other or, b) create two relations to handle each case. 2) since "action" will always be unsafe, it MUST NOT be applied to elements already defined as "safe" by the media type (HTML.A, HTML.LINK, HTML.IFRAME, HTML.IMG, HTML.FORM@method="get", etc.). Wording should be added that makes this clear. mca +1.859.757.1449 skype: mca.amundsen http://amundsen.com/blog/ http://twitter.com/mamund https://github.com/mamund http://www.linkedin.com/in/mikeamundsen On Thu, Jan 31, 2013 at 2:10 PM, Ioseb Dzmanashvili < ioseb.dzmanashvili@gmail.com> wrote: > Dear All, > > I've submitted new draft of the 'create' link relation type: > http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-00 > > Description: > - The link relation is intentionally generic, and it can be used with > multiple media types in a wide variety of use cases. > - When included in a resource which represents a collection, the 'form' > link relation identifies a target resource that represents the form for > adding a new member to the context collection. > - The target IRI points to a resource that is responsible to perform an > action that may affect state of the context resource or > initiate process. > > Could you please review? > Thanks in advance! > > Best regards, > ioseb > -- > Ioseb Dzmanashvili > AzRy LLC > Software Architect > #8, Chachava str. > Tbilisi, 0159, Georgia > Mobile: +(995) 99753388 > github.com/ioseb > pecl.php.net/user/ioseb > twitter.com/iosebi > > _______________________________________________ > link-relations mailing list > link-relations@ietf.org > https://www.ietf.org/mailman/listinfo/link-relations > > --047d7bfcef7403d52404d4a9d625 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable My initial comments are:

1) "action" will alwa= ys be unsafe, but MAY be either idempotent (PUT/DELETE) or non-idempotent (= PATCH/POST). This is a problem. Either a) establish it as one or the other = or, b) create two relations to handle each case.

2) since "action" will always be unsafe, it M= UST NOT be applied to elements already defined as "safe" by the m= edia type (HTML.A, HTML.LINK, HTML.IFRAME, HTML.IMG, HTML.FORM@method=3D&qu= ot;get", etc.). Wording should be added that makes this clear.





On Thu, Jan 31, 2013 at 2:10 PM, Ioseb D= zmanashvili <ioseb.dzmanashvili@gmail.com> wrote:=
Dear All,

I've submit= ted new draft of the 'create' link relation type: http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-li= nk-relation-00

Description:
- The link relation is intention= ally generic, and it can be used with =A0multiple media types in a wide var= iety of use cases.
- When included in a resource which represents= a collection, the 'form' =A0link relation identifies a target reso= urce that represents the form for adding a new member to the context collec= tion.
- The target IRI points to a resource that is responsible to perform a= n action that may affect state of the context resource or
=A0init= iate process.

Could you please review?
Thanks in advance!

Best regards,
ioseb
--=A0
Ioseb Dzmanashvili
AzRy LLC
Software Archi= tect
#8, Chachava str.
Tbilisi, 0159, Georgia
Mobile: +(995) 99753388

_____________________________________________= __
link-relations mailing list
link-relations@ietf.org
https://www.ietf.org/mailman/listinfo/link-relations


--047d7bfcef7403d52404d4a9d625-- From darrel@tavis.ca Fri Feb 1 06:08:51 2013 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 355AE21F8C17 for ; Fri, 1 Feb 2013 06:08:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] 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 sHZqVOVHuie6 for ; Fri, 1 Feb 2013 06:08:50 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 33BBB21F9136 for ; Fri, 1 Feb 2013 06:08:45 -0800 (PST) Received: from OAK ([70.24.178.200]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MMChx-1U4JAT0hQb-007tyf; Fri, 01 Feb 2013 09:08:42 -0500 From: "Darrel Miller" To: "'Markus Lanthaler'" References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> <-3128426172162859719@unknownmsgid> <01fa01ce0083$65105cd0$2f311670$@lanthaler@gmx.net> In-Reply-To: <01fa01ce0083$65105cd0$2f311670$@lanthaler@gmx.net> Subject: RE: NEW RELATION: action Date: Fri, 1 Feb 2013 09:08:39 -0500 Message-ID: <022b01ce0085$a4452b90$eccf82b0$@tavis.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQKmyaFO6FvkdPSxcObh3XCqSOoVowFdhwD1An8Mq8wBiNH9JAEtA+lKAabIR9QBsBCVSZZkKpTg Content-Language: en-ca X-Provags-ID: V02:K0:l+zdgsw91ySBHOlkhk/GbdMQFeORIj4KzCrTZNhH/4T q+wb08vbDUiSCVreXivvWbO11omf5XNVxmO0fZLNOujWiN6Elc V5hNnj/PWcSzfpujdJOd8ND+V8s0gWLnaptsqISkeKemugCP3f +IUSQW7ncdx/T1uX3Gg56E4CSy4zL/JwWAcpcpUZcir+HsbsxQ VKuQPoTA0OOHGPrpHz6IOScUSp8/9ezxpXkw5MID0votRfX2wa N/N9hviL82+EyBHSC/ih9wEn+HDBg2tPUMJoV/lqZlPxh+EXVM m/BDiega9aQl5/pkq6pjVGgDzdhoS6bZGEProVsj0PIQY/x6q9 MrwXT8Me2LXb/zsO2d+4= X-Mailman-Approved-At: Fri, 01 Feb 2013 08:22:00 -0800 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: Fri, 01 Feb 2013 14:49:50 -0000 Markus, > -----Original Message----- > From: Markus Lanthaler [mailto:markus.lanthaler@gmx.net] > > Hmm.. the reason I do not particularly like it is because it basically means > nothing. It's basically that same as "accepts-post", and POST has no semantics > at all. It "works" in HTML because there's a human reading and interpreting > the text. If you would be going to use that in machine-to-machine > communication you would either need to infer the meaning from the target > URL (which you shouldn't because they are opaque) or use something else (a > title, a second rel, etc.) to convey the meaning. AFAICS, you cannot do > anything useful with just rel="action". > I completely agree that "action" means nothing to client code other than "this is some unsafe operation to be performed on a resource". I also agree that is has very little value to m2m clients. However, 99% of the software I have written over the past 18 years has been operated by a human. So, I'm much more concerned about the human driven scenario. Over the past few years my tendency has been to write client software that focuses on presenting information to humans and then capturing their intent. I rarely need my user-agent to actually understand the consequences of the user's action. It's only job is to faithfully relay the user's intent to the resource. I recognize that this rel is not going to be valuable to everyone. That's fine with me. > > P.S.: Darrel, you replied just to me > Yeah, I always make that mistake when replying in the Gmail interface. I forwarded the message to the list after I realized my mistake. Darrel From mca@amundsen.com Fri Feb 1 08:18:40 2013 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 188D921E805D for ; Fri, 1 Feb 2013 08:18:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.723 X-Spam-Level: X-Spam-Status: No, score=0.723 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_46=0.6, J_CHICKENPOX_72=0.6, NO_RELAYS=-0.001] 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 sBDiciszoj2F for ; Fri, 1 Feb 2013 08:18:38 -0800 (PST) Received: from mail-we0-x22b.google.com (we-in-x022b.1e100.net [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id A8B1321E8039 for ; Fri, 1 Feb 2013 08:18:37 -0800 (PST) Received: by mail-we0-f171.google.com with SMTP id u54so3005154wey.2 for ; Fri, 01 Feb 2013 08:18:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=uHYT0GbbZfmbRCgGIGclDKYiZZ1rgHweCfCzPSSXYIE=; b=EhjsHOX8N6VYLIpzUA9PthN3YAUf8x7Y8oeOwgsZvh+0Flv5CK6nB/zJPY0/OyVtWN YoOIboMnhZw4YySfcurcM5MhJjmXnK38l2dEiddz8gbYUcNTuapU8+QJjbf6KlxpA616 3mNy7Jkgw3Y6Dv6vlUf8DwOER6lfIFask++Aj0jE3xUKj7inpSaJSfuJQDsi/A4130Fu AjoTXCDq6IrT96eWoxs8eaUxViOpIZOYKN0TWtxOqOxaMQnrI9J6zKxkFFiOmJyPPedk 7YCFsLDTH8MZe26X5jcZm8g/l+YJowmyIvHy8mM/DPa82Y9PP9n/6ZgaSB6bQ+1B91wx CdTg== X-Received: by 10.180.97.102 with SMTP id dz6mr3904298wib.3.1359735515566; Fri, 01 Feb 2013 08:18:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.166.36 with HTTP; Fri, 1 Feb 2013 08:18:15 -0800 (PST) In-Reply-To: <9090DD8D497247E7BD1C3FE30231A0CC@gmail.com> References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> <510ba796.09df0e0a.3a70.fffff0f4SMTPIN_ADDED_BROKEN@mx.google.com> <084F8A1FB98040A1BD1B987D3CF3D518@gmail.com> <9090DD8D497247E7BD1C3FE30231A0CC@gmail.com> From: mca Date: Fri, 1 Feb 2013 11:18:15 -0500 Message-ID: Subject: Re: NEW RELATION: action To: Ioseb Dzmanashvili Content-Type: multipart/alternative; boundary=f46d043bdde864d1c704d4ac183f X-Gm-Message-State: ALoCoQn322mH/sfcmZUSJbT8bZdqw1MfQ/GBZeWHSAIpJ5rnuTGQf7p5Wuaz3el17X8PLcWMfd4J X-Mailman-Approved-At: Fri, 01 Feb 2013 08:22:02 -0800 Cc: darrel@tavis.ca, 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: Fri, 01 Feb 2013 16:18:40 -0000 --f46d043bdde864d1c704d4ac183f Content-Type: text/plain; charset=ISO-8859-1 > 1) "action" will always be unsafe, but MAY be either idempotent (PUT/DELETE) or non-idempotent (PATCH/POST). This is a problem. Either a) establish it as one or the other or, b) create two relations to handle each case. Regarding idempotency i do not have clear use cases right now(some examples would be great here), hence no idea what second link relation type should be. Establishing the "action" as unsafe looks more appropriate for me at the moment. Consider a case where a sent an unsafe request to a server and get NO answer back. I don't know what happened. Should I re-try? if this is an idempotent action (PUT/DELETE) I know I can retry w/o unwanted side-effects. Server might say "that record is already modified , or "OK, done", etc. and I'd be satisfied. But if the action was non-idempotent (PATCH/POST), then I proly won't re-try since it might result in multiple entries, etc. @rel="action" doesn't tell me whether the unsafe action I am about to commit is idempotent or non-idempotent. This is a problem. It means I must rely on human-readable docs for the answer and that means this is unlikely to work for "bot" or automated client cases. mca +1.859.757.1449 skype: mca.amundsen http://amundsen.com/blog/ http://twitter.com/mamund https://github.com/mamund http://www.linkedin.com/in/mikeamundsen On Fri, Feb 1, 2013 at 10:16 AM, Ioseb Dzmanashvili < ioseb.dzmanashvili@gmail.com> wrote: > I'm guessing something went wrong with email thread. I see some messages > in mail list which missed my mailbox and do not see @mamund's email message > at all. I'm including combined conversation in this email: > > Ioseb Dzmanashvili wrote: > > Hi Mike, > > Thanks for feedback! > > > 1) "action" will always be unsafe, but MAY be either idempotent > (PUT/DELETE) or non-idempotent (PATCH/POST). This is a problem. Either a) > establish it as one or the other or, b) create two relations to handle each > case. > > Regarding idempotency i do not have clear use cases right now(some > examples would be great here), hence no idea what second link relation type > should be. Establishing the "action" as unsafe looks more appropriate for > me at the moment. > > > 2) since "action" will always be unsafe, it MUST NOT be applied to > elements already defined as "safe" by the media type (HTML.A, HTML.LINK, > HTML.IFRAME, HTML.IMG, HTML.FORM@method="get", etc.). Wording should be > added that makes this clear. > > Accepted! > > Cheers, > ioseb > > Mike Amundsen wrote: > > My initial comments are: > > 1) "action" will always be unsafe, but MAY be either idempotent > (PUT/DELETE) or non-idempotent (PATCH/POST). This is a problem. Either a) > establish it as one or the other or, b) create two relations to handle each > case. > > 2) since "action" will always be unsafe, it MUST NOT be applied to > elements already defined as "safe" by the media type (HTML.A, HTML.LINK, > HTML.IFRAME, HTML.IMG, HTML.FORM@method="get", etc.). Wording should be > added that makes this clear. > > mca > > On Friday, February 01, 2013 2:26 PM, Darrel Miller wrote: > > > It isn't different. It allows that same functionality to be embedded in > any > > hypermedia type, Or even just in link headers. I think the fact that you > > can do it in HTML further validates this proposal. > > Hmm.. the reason I do not particularly like it is because it basically > means > nothing. It's basically that same as "accepts-post", and POST has no > semantics at all. It "works" in HTML because there's a human reading and > interpreting the text. If you would be going to use that in > machine-to-machine communication you would either need to infer the meaning > from the target URL (which you shouldn't because they are opaque) or use > something else (a title, a second rel, etc.) to convey the meaning. AFAICS, > you cannot do anything useful with just rel="action". > > > P.S.: Darrel, you replied just to me > > -- > Markus Lanthaler > @markuslanthaler > > Ioseb, > > On Fri, Feb 1, 2013 at 6:42 AM, Ioseb Dzmanashvili gmail.com> wrote: > Draft doesn't mention anything about GET request to "action" links for the > moment, though i think service implementors can use: 3xx status codes to > redirect user agent somewhere else, return 4xx(405 Method Not Allowed for > example) etc.... But the action must be performed only if client sends POST > request. > > I would be tempted to just use the GET as a placeholder for documentation > on what the POST does. > > Darrel > > Markus, > > > On Fri, Feb 1, 2013 at 6:31 AM, Markus Lanthaler gmx.net> wrote: > > Talking about HTML, how is that different from using an empty form (just > submit button) and @method=POST? > > > It isn't different. It allows that same functionality to be embedded in > any hypermedia type, Or even just in link headers. I think the fact that > you can do it in HTML further validates this proposal. > > Darrel > > > cheers, > ioseb > > On Friday, February 1, 2013 at 3:42 PM, Ioseb Dzmanashvili wrote: > > Hi Markus, > > Draft doesn't mention anything about GET request to "action" links for the > moment, though i think service implementors can use: 3xx status codes to > redirect user agent somewhere else, return 4xx(405 Method Not Allowed for > example) etc.... But the action must be performed only if client sends POST > request. > > P.S. > i truly believe that such links must not be exposed to public unless > client doesn't have enough permissions. > > Cheers, > ioseb > > On Friday, February 1, 2013 at 3:31 PM, Markus Lanthaler wrote: > > On Friday, February 01, 2013 10:45 AM, Ioseb Dzmanashvili wrote: > > To me this smells a lot like a (REST-) anti pattern. > > > I do not agree. Which REST constraint is violated in this case? > Using POST without body is valid and "action" links expose > availability of actions which may be performed: > > * without knowing media type; > * without need to construct whole message(to conform PUT's > replace semantics); > * no need to use PATCH > * "action" links can be filtered by client and displayed to > user(and here we do not even need additional link relation > extensions) > > > The problem is they can just be filtered by clients who know about them. > How would a generic crawler know it has to avoid those action links? For > example, looking at your example: > > > < HTTP/1.1 200 OK > < Content-Type: ... > < Content-Length: ... > < Link: ; rel="action urn:restart"; title="Restart" > > Imagine that the link would be embedded in a HTML page: > > Restart > > What would happen if a crawler follows that link? Would the service be > restarted? Assuming that you say links with this relation type just accept > POST (and I think that's what Jan was concerned about because it wasn't > clear in your initial mail), would it result in an error because it uses > GET? > > > On Friday, February 1, 2013 at 4:31 AM, Darrel Miller wrote: > > Yes there are other ways of doing this, but I can't see any > negative impacts on the system by using this approach. > > [..] > > The huge benefit in my mind of this link relation is that it > opens the door for generic clients to be able to start doing > some simple write operations. > > > Talking about HTML, how is that different from using an empty form (just > submit button) and @method=POST? > > > > > -- > Markus Lanthaler > @markuslanthaler > > > --f46d043bdde864d1c704d4ac183f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
=
> 1) "action&qu= ot; will always be unsafe, but MAY be either idempotent (PUT/DELETE) or non= -idempotent (PATCH/POST). This is a problem. Either a) establish it as one = or the other or, b) create two relations to handle each case.

Regarding idempotency i do not have clear use cases rig= ht now(some examples would be great here), hence no idea what second link r= elation type should be. Establishing the "action" as unsafe looks= more appropriate for me at the moment.=A0

Consider a case where a sent an unsa= fe request to a server and get NO answer back. I don't know what happen= ed. Should I re-try? if this is an idempotent action (PUT/DELETE) I know I = can retry w/o unwanted side-effects. Server might say "that record is = already=A0modified=A0, or "OK, done", etc. and I'd be satisfi= ed. =A0But if the action was non-idempotent=A0(PATCH/POST), then I proly wo= n't re-try since it might result in multiple entries, etc.

@rel=3D"action" doesn't tell me whether t= he unsafe action I am about to commit is idempotent or non-idempotent. =A0T= his is a problem. It means I must rely =A0on human-readable docs for the an= swer and that means this is unlikely to work for "bot" or automat= ed client cases.




On Fri, Feb 1, 2013 at 10:16 AM, Ioseb D= zmanashvili <ioseb.dzmanashvili@gmail.com> wrote:=
I'm guessing something went wrong with email threa= d. I see some messages in mail list which missed my mailbox and do not see = @mamund's email message at all. I'm including combined conversation= in this email:

I= oseb Dzmanashvili wrote:

Hi Mike,=A0
Thanks for feedback!

> 1) "act= ion" will always be unsafe, but MAY be either idempotent (PUT/DELETE) = or non-idempotent (PATCH/POST). This is a problem. Either a) establish it a= s one or the other or, b) create two relations to handle each case.

Regarding idempotency i do not have clear use cases rig= ht now(some examples would be great here), hence no idea what second link r= elation type should be. Establishing the "action" as unsafe looks= more appropriate for me at the moment.=A0

> 2) since "action" will always be unsafe,= it MUST NOT be applied to elements already defined as "safe" by = the media type (HTML.A, HTML.LINK, HTML.IFRAME, HTML.IMG, HTML.FORM@method= =3D"get", etc.). Wording should be added that makes this clear.

Accepted!

Cheers,
io= seb

Mike Amundsen wrote:

My initial com= ments are:

1) "action" will always be unsafe, but MAY be eith= er idempotent (PUT/DELETE) or non-idempotent (PATCH/POST). This is a proble= m. Either a) establish it as one or the other or, b) create two relations t= o handle each case.

2) since "action" will always be unsafe, it M= UST NOT be applied to elements already defined as "safe" by the m= edia type (HTML.A, HTML.LINK, HTML.IFRAME, HTML.IMG, HTML.FORM@method=3D&qu= ot;get", etc.). Wording should be added that makes this clear.

mca
On Friday, February 01, 2013 2:26 PM, Darrel Miller wrote:

> It isn't different. =A0It allows= that same functionality to be embedded in
any
> hypermedia type, Or even just in link headers. =A0I= think the fact that you
> can do it in HTML further validates= this proposal.

Hmm.. the reason I do not particul= arly like it is because it basically means
nothing. It's basically that same as "accepts-post", and= POST has no
semantics at all. It "works" in HTML becau= se there's a human reading and
interpreting the text. If you = would be going to use that in
machine-to-machine communication you would either need to infer the me= aning
from the target URL (which you shouldn't because they a= re opaque) or use
something else (a title, a second rel, etc.) to= convey the meaning. AFAICS,
you cannot do anything useful with just rel=3D"action".


P.S.: Darrel, you replied just to me

--
Markus Lanthaler
@markuslanth= aler
Ioseb,

On Fri, Feb 1, 2= 013 at 6:42 AM, Ioseb Dzmanashvili <ioseb.dzmanashvili at gmail.com> wrote:
Draft doesn't mention anything about GET request to "action&q= uot; links for the moment, though i think service implementors can use: 3xx= status codes to redirect user agent somewhere else, return 4xx(405 Method = Not Allowed for example) etc.... But the action must be performed only if c= lient sends POST request.
I would be tempted to just use the GET as a p= laceholder for documentation on what the POST does.

Darrel
Markus,


On Fri, Feb 1, 2013 at= 6:31 AM, Markus Lanthaler <markus.lanthaler at gmx.net> wrote:

Talkin= g about HTML, how is that different from using an empty form (just submit b= utton) and @method=3DPOST?


It isn't dif= ferent. =A0It allows that same functionality to be embedded in any hypermed= ia type, Or even just in link headers. =A0I think the fact that you can do = it in HTML further validates this proposal.

Darrel
<= div>

cheers,
<= div>ioseb
=20

On Friday, February 1, 2013 at 3= :42 PM, Ioseb Dzmanashvili wrote:

Hi Markus,=A0

Draft doesn'= ;t mention anything about GET request to "action" links for the m= oment, though i think service implementors can use: 3xx status codes to red= irect user agent somewhere else, return 4xx(405 Method Not Allowed for exam= ple) etc.... But the action must be performed only if client sends POST req= uest.

P.S.
i truly believe that such links must not= be exposed to public unless client doesn't have enough permissions.=A0=

Cheers,
ioseb=A0
=20

On Friday, February 1, 2013 at 3= :31 PM, Markus Lanthaler wrote:

On Friday, February 01, 2013 10:45= AM, Ioseb Dzmanashvili wrote:

To me this smells a lot like a (REST-= ) anti pattern.

I do not agree. Which REST constraint is v= iolated in this case?
Using POST without body is valid and "= action" links expose
availability of actions which may be pe= rformed:

* without knowing media type;
* without need = to construct whole message(to conform PUT's
replace semanti= cs);
* no need to use PATCH
* "action" links= can be filtered by client and displayed to
user(and here we do not even need additional link relation
e= xtensions)

The problem is they = can just be filtered by clients who know about them. How would a generic cr= awler know it has to avoid those action links? For example, looking at your= example:


< HTTP/1.1 200 OK
< Cont= ent-Type: ...
< Content-Length: ...
< Link: </= service/manager>; rel=3D"action urn:restart"; title=3D"Re= start"

Imagine that the link would be embedded in a HTML page:=

<a href=3D"/service/manager" rel=3D&= quot;action urn:restart">Restart</a>

What would happen if a crawler follows that link? Would the service be rest= arted? Assuming that you say links with this relation type just accept POST= (and I think that's what Jan was concerned about because it wasn't= clear in your initial mail), would it result in an error because it uses G= ET?


On Friday, February 1, 2013 at 4:31 AM, = Darrel Miller wrote:

Yes there are other ways of doing this, but I can't see any
negative impacts on the system by using this approach.

=
[..]

The huge benefit in my mind of this link= relation is that it
opens the door for generic clients to be abl= e to start doing
some simple write operations.

Talking about HTML, how is that different from using an empty form (= just submit button) and @method=3DPOST?




--
Markus Lanthaler
= @markuslanthaler
=20 =20 =20 =20


--f46d043bdde864d1c704d4ac183f-- From jan.algermissen@nordsc.com Fri Feb 1 08:31:03 2013 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 C2CC221E8096 for ; Fri, 1 Feb 2013 08:31:03 -0800 (PST) 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 HpJYeOXBFivO for ; Fri, 1 Feb 2013 08:31:02 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id 8D28221E8030 for ; Fri, 1 Feb 2013 08:31:02 -0800 (PST) Received: from [10.90.128.227] ([87.253.171.198]) by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis) id 0MMnOB-1U3nIJ3oMR-008Lq4; Fri, 01 Feb 2013 17:31:01 +0100 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: NEW RELATION: action From: Jan Algermissen In-Reply-To: Date: Fri, 1 Feb 2013 17:31:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> To: darrel@tavis.ca X-Mailer: Apple Mail (2.1499) X-Provags-ID: V02:K0:ThTLF2/5OX1bLSvTJzFqOk3BH7wgUgM8GlhzydlXXZg CfxI5S/X4i3tmS/0KAQckIPqLP0aHiiR/p3TJ4hSCYt9+t/vF9 dZAzz043+Mlpvibkj4hRJySlzFwHZZEynl5QqntfgIlhTY5YwS 95dNceY1j9C6NsCaI2aA7D6opUebgqpUtfss4YO1o4l2+05h79 Lx01fezW/kp6vpHPk4TFfd5Xa66If9xaOjGOYE6V/XjnRzfKw6 KAQsbxJ3zhe/DswZe2L0FjcQYC1vAYfwrGzULdH75ygq+LevE4 Y1+pSY/2o4CJfG98oz4zVMmjX58K7RKH9pSEDWUVeGYt0NB9PZ p6lo5hZGPUVR9cWdS5+fT7C+PFG6JTpNO9y0woseFKGeFnQJqY zbjx2EkyxeB1g== Cc: link-relations@ietf.org, 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: Fri, 01 Feb 2013 16:31:03 -0000 On 01.02.2013, at 01:31, Darrel Miller wrote: > Hey Jan, >=20 > I thought of you as soon as I saw this. I know we have traveled this = road before and you are not a fan, but let me give you a few examples = that I can think of and you let me know what "harm" they might cause. =20= >=20 > It can be used for changing a resource to a new state. >=20 > > GET /light/bedroom > > > < 200 OK > < Link : ; rel=3D"action"; = title=3D"On" > Off >=20 > This could absolutely be done with PUT, however the client needs to be = much smarter in order to know how to formulate the appropriate body to = submit a PUT request to do exactly the same thing.=20 But now client would ever PUT/POST to such a link, without understanding = it. Or? Given it requires understanding, the need for a generic = mechanism is gone. Just use a specific link rel instead. Much cleaner, = IMHO. For the sake of displaying a button: this can always be done if there is = a title in the link. >=20 > It can be used as a way of selecting from a set of options >=20 > > GET /survey/12321323/favouritefruit > > > < 200 OK > < Content-Type: application/hal+xml >=20 > > =20 > =20 > =20 > >=20 > Yes there are other ways of doing this, but I can't see any negative = impacts on the system by using this approach. In general: what is the need for a generic mechanism, if no client would = interact with the target unless it understands the rel anyhow? I'd say it's pretty much YAGNI. >=20 >=20 > It can be used for triggering a part of a workflow process >=20 > > GET /employee/344/timesheet/20130131 > > > < 200 OK > < Content-Type: application/hal+xml >=20 > > =20 > >=20 >=20 > I realize this last example steps into "it's not a self-descriptive = request" territory, but let's not get sidetracked into that debate. Yes - but it is another aspect I'd 'object' to. >=20 > The huge benefit in my mind of this link relation is that it opens the = door for generic clients to be able to start doing some simple write = operations. This is what I do not see happening - you? Jan > So far, most of the generic clients that people have been playing = around with have been purely read-only. This link relation allows a = generic client to display some buttons to a human and allow the human to = "poke a stick" at the resource and actually have an impact. >=20 > As I mentioned on twitter to Isoeb, I do think this link relation has = the potential to be abused, however, I do believe it has sufficient = value to mitigate those risks. >=20 > Darrel >=20 >=20 > On Thu, Jan 31, 2013 at 6:11 PM, Jan Algermissen = wrote: > Hi Ioseb, >=20 > can you explain your use case? >=20 > To me this smells a lot like a (REST-) anti pattern. >=20 > For example, instead of invoking an action resource like >=20 > GET /content/article/22/publish >=20 > you'd rather set it's state: >=20 > PUT /content/article/22/publish >=20 > > ... > published > ... > >=20 > No need for link and 'action' link rel, because you know the resource = to change anyhow. >=20 >=20 > Maybe I am missing your point though. >=20 > Jan >=20 >=20 >=20 > On 31.01.2013, at 20:10, Ioseb Dzmanashvili = wrote: >=20 > > Dear All, > > > > I've submitted new draft of the 'create' link relation type: = http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-0= 0 > > > > Description: > > - The link relation is intentionally generic, and it can be used = with multiple media types in a wide variety of use cases. > > - When included in a resource which represents a collection, the = 'form' link relation identifies a target resource that represents the = form for adding a new member to the context collection. > > - The target IRI points to a resource that is responsible to perform = an action that may affect state of the context resource or > > initiate process. > > > > Could you please review? > > Thanks in advance! > > > > Best regards, > > ioseb > > -- > > Ioseb Dzmanashvili > > AzRy LLC > > Software Architect > > #8, Chachava str. > > Tbilisi, 0159, Georgia > > Mobile: +(995) 99753388 > > github.com/ioseb > > pecl.php.net/user/ioseb > > twitter.com/iosebi > > _______________________________________________ > > link-relations mailing list > > link-relations@ietf.org > > https://www.ietf.org/mailman/listinfo/link-relations >=20 > _______________________________________________ > link-relations mailing list > link-relations@ietf.org > https://www.ietf.org/mailman/listinfo/link-relations >=20 From jan.algermissen@nordsc.com Fri Feb 1 08:32:25 2013 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 E7CF021F8D18 for ; Fri, 1 Feb 2013 08:32:25 -0800 (PST) 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_43=0.6, J_CHICKENPOX_72=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 o145sN5-8o1u for ; Fri, 1 Feb 2013 08:32:21 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB2A21F8D06 for ; Fri, 1 Feb 2013 08:32:21 -0800 (PST) Received: from [10.90.128.227] ([87.253.171.198]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0MdArm-1UIIBl0iR8-00IF7H; Fri, 01 Feb 2013 17:32:19 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: NEW RELATION: action From: Jan Algermissen In-Reply-To: <01a701ce006f$ad6aa3a0$083feae0$@lanthaler@gmx.net> Date: Fri, 1 Feb 2013 17:32:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> <01a701ce006f$ad6aa3a0$083feae0$@lanthaler@gmx.net> To: "Markus Lanthaler" X-Mailer: Apple Mail (2.1499) X-Provags-ID: V02:K0:zcK3M3KlaUVQXA3GJPGP85nobIJhmivAIWTLq479wAk tmUNRT/GzyreUVYC/gPZLsiVpfH9UG993z0yc7hJ5dIQR0wmg5 vQx/yzNLfxNucr8o6VpydU748KLZtkyqn7bCSs1PNLXcT9M80C v/UcS93rVZKzEP2d3xnKo6JwhrgoxX3mXavssCI61yEbZc2sR4 6Ps+VTsLL12vCme4OycXAVzm9CFHX/JD4O7uQ0oHOCeFm7NLJs CzS9KJHFPpnFnnILbIKAkKhJJqQ/IgXQjrvBKiG2eHYsBoS0fM DpYfPMsk9AOmkSf22vaVyLr46kR7kWl8tIuvbP6n/sv0VwvlvP yVecI9exdTYkmUQ2IBap73tpufJtCXtU2bRdb7ei4DCoohkZTZ ICMogJJBRo1AQ== Cc: darrel@tavis.ca, link-relations@ietf.org, '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: Fri, 01 Feb 2013 16:32:26 -0000 On 01.02.2013, at 12:31, "Markus Lanthaler" = wrote: > On Friday, February 01, 2013 10:45 AM, Ioseb Dzmanashvili wrote: >=20 >>> To me this smells a lot like a (REST-) anti pattern. >>=20 >> I do not agree. Which REST constraint is violated in this case? >> Using POST without body is valid and "action" links expose >> availability of actions which may be performed:=20 >>=20 >> * without knowing media type; >> * without need to construct whole message(to conform PUT's >> replace semantics); >> * no need to use PATCH=20 >> * "action" links can be filtered by client and displayed to >> user(and here we do not even need additional link relation >> extensions) >=20 > The problem is they can just be filtered by clients who know about = them. How would a generic crawler know it has to avoid those action = links? For example, looking at your example: >=20 >=20 > < HTTP/1.1 200 OK > < Content-Type: ... > < Content-Length: ... > < Link: ; rel=3D"action urn:restart"; = title=3D"Restart" >=20 > Imagine that the link would be embedded in a HTML page: >=20 > Restart >=20 > What would happen if a crawler follows that link? That is another concern, but a GET should be save anyhow - eh? Jan > Would the service be restarted? Assuming that you say links with this = relation type just accept POST (and I think that's what Jan was = concerned about because it wasn't clear in your initial mail), would it = result in an error because it uses GET? >=20 >=20 > On Friday, February 1, 2013 at 4:31 AM, Darrel Miller wrote: >=20 >> Yes there are other ways of doing this, but I can't see any >> negative impacts on the system by using this approach. >>=20 >> [..] >>=20 >> The huge benefit in my mind of this link relation is that it >> opens the door for generic clients to be able to start doing >> some simple write operations. =20 >=20 > Talking about HTML, how is that different from using an empty form = (just submit button) and @method=3DPOST? >=20 >=20 >=20 >=20 > -- > Markus Lanthaler > @markuslanthaler >=20 From jan.algermissen@nordsc.com Fri Feb 1 08:39:01 2013 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 D9C8321F8F5E for ; Fri, 1 Feb 2013 08:39:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.300, 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 3tyTV8KCTkkQ for ; Fri, 1 Feb 2013 08:39:01 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by ietfa.amsl.com (Postfix) with ESMTP id 299B021F8F5C for ; Fri, 1 Feb 2013 08:39:01 -0800 (PST) Received: from [10.90.128.227] ([87.253.171.198]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0Ls7Sx-1UyjJU3o9H-013o48; Fri, 01 Feb 2013 17:39:00 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: NEW RELATION: action From: Jan Algermissen In-Reply-To: <022b01ce0085$a4452b90$eccf82b0$@tavis.ca> Date: Fri, 1 Feb 2013 17:39:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6D2125B5-02DE-4016-86BA-38F8FA100DB4@nordsc.com> References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> <-3128426172162859719@unknownmsgid> <01fa01ce0083$65105cd0$2f311670$@lanthaler@gmx.net> <022b01ce0085$a4452b90$eccf82b0$@tavis.ca> To: "Darrel Miller" X-Mailer: Apple Mail (2.1499) X-Provags-ID: V02:K0:Mv9DwJi1sqyTiK2UO1FWG2DAL3Jd2Ay8Ur2m9l5i2g8 DWOVbtD+yjmV3i+sUAM+dCYh+r4y0w/3OxYTlwdON20Y+I4dm8 8AhfIBeoEhp+mCXEnpxUq43GRp2U5grrf/54lf+eILModwRONh jgPsQlMy7a2YO+DEnB5HlI70VPfcR7XX/jfWVVYIniMX9jatCZ M4DW6IhOqKGotSIiet5GOSYb1D2hA3yYPj8C8h6UU0V/4L3OFE BKPt9Fm206Ji0vEcTcmuVKYOgSb9QyPWbEY7340EoaYxFZTqT/ S0A1tLUp0UAwu8oRX0j+WPBiftWZrLcnlj9ImsmEsJKfoXIjRO vgK6oofYac7cW0zqoPZ+kunXD36ewT2BykzpGJy56qamyC04XO PzlDlR9adXQOQ== 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: Fri, 01 Feb 2013 16:39:02 -0000 On 01.02.2013, at 15:08, "Darrel Miller" wrote: > Markus, >=20 >> -----Original Message----- >> From: Markus Lanthaler [mailto:markus.lanthaler@gmx.net] >>=20 >> Hmm.. the reason I do not particularly like it is because it = basically > means >> nothing. It's basically that same as "accepts-post", and POST has no > semantics >> at all. It "works" in HTML because there's a human reading and > interpreting >> the text. If you would be going to use that in machine-to-machine >> communication you would either need to infer the meaning from the = target >> URL (which you shouldn't because they are opaque) or use something = else (a >> title, a second rel, etc.) to convey the meaning. AFAICS, you cannot = do >> anything useful with just rel=3D"action". >>=20 >=20 > I completely agree that "action" means nothing to client code other = than > "this is some unsafe operation to be performed on a resource". I also = agree > that is has very little value to m2m clients. =20 >=20 > However, 99% of the software I have written over the past 18 years has = been > operated by a human. So, I'm much more concerned about the human = driven > scenario. Over the past few years my tendency has been to write = client > software that focuses on presenting information to humans and then = capturing > their intent. I rarely need my user-agent to actually understand the > consequences of the user's action. It's only job is to faithfully = relay the > user's intent to the resource. So then ... if your UA sees Link: ; rel=3D"pub";title=3D"Publish"=20 just display a [Publish] Button. (Set aside the fact that I deeply dislike action-URIs and would = wholeheartedly 'fight' anything that can possibly lead people to think = it is a REST best practice of some sort) Avoiding them yields better systems, IMHO. Jan >=20 > I recognize that this rel is not going to be valuable to everyone. = That's > fine with me. >=20 >>=20 >> P.S.: Darrel, you replied just to me >>=20 > Yeah, I always make that mistake when replying in the Gmail interface. = I > forwarded the message to the list after I realized my mistake. >=20 > Darrel >=20 > _______________________________________________ > link-relations mailing list > link-relations@ietf.org > https://www.ietf.org/mailman/listinfo/link-relations From darrel.miller@gmail.com Fri Feb 1 09:00:33 2013 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 E68FF21E80A3 for ; Fri, 1 Feb 2013 09:00:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.888 X-Spam-Level: X-Spam-Status: No, score=-2.888 tagged_above=-999 required=5 tests=[AWL=0.710, 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 oS7bhtg8fulw for ; Fri, 1 Feb 2013 09:00:32 -0800 (PST) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) by ietfa.amsl.com (Postfix) with ESMTP id 880B521E80B8 for ; Fri, 1 Feb 2013 09:00:32 -0800 (PST) Received: by mail-lb0-f170.google.com with SMTP id ge1so4780857lbb.29 for ; Fri, 01 Feb 2013 09:00:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=eT2ERJpo2vZTjnrKT37LiDukIt4aiQdRxhjAdjtIVKc=; b=e9VZUnUT3Gud3lNX0LNdVxKkYM1YMmV/QZrTpLQT0e9zh256MXZU/JhfOLV19hWnQi LCFtBNuXQVEYHPgcLLKSHIQf/9RGD3cHEgctohGdaH6+q9F529blUm1Npiper2jK87d9 yJB6WkxFTQH8C4hBusT1OS5RGwP3z3clxOXwKFX1G+KAJdvTA7qvVsXupjmkHv431ZA+ dxhOKILw7O05eF5mak0zuC/NM4NH5UxYXtNHeX903+lXyYk64ISR+j+S4tmvu006NXPs hpijsGOHjyqOhCUqNtO66vcnGmki8iU29GmKnAzgFzHEhiYQzQoOYOwpODQ67lO3CdgI 6q+g== MIME-Version: 1.0 X-Received: by 10.152.162.1 with SMTP id xw1mr11923255lab.3.1359738031254; Fri, 01 Feb 2013 09:00:31 -0800 (PST) Received: by 10.152.109.204 with HTTP; Fri, 1 Feb 2013 09:00:30 -0800 (PST) In-Reply-To: <6D2125B5-02DE-4016-86BA-38F8FA100DB4@nordsc.com> References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> <-3128426172162859719@unknownmsgid> <022b01ce0085$a4452b90$eccf82b0$@tavis.ca> <6D2125B5-02DE-4016-86BA-38F8FA100DB4@nordsc.com> Date: Fri, 1 Feb 2013 12:00:30 -0500 Message-ID: Subject: Re: NEW RELATION: action From: Darrel Miller To: Jan Algermissen Content-Type: multipart/alternative; boundary=f46d042ef4a5572e2a04d4acaead Cc: link-relations X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: darrel@tavis.ca List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 17:00:34 -0000 --f46d042ef4a5572e2a04d4acaead Content-Type: text/plain; charset=ISO-8859-1 Jan, On Fri, Feb 1, 2013 at 11:39 AM, Jan Algermissen wrote: > > > So then ... if your UA sees > > > Link: ; rel="pub";title="Publish" > > > just display a [Publish] Button. > > First, "pub" is not a valid registered link relation, nor is it valid syntax for an extended link relation. Second, what additional semantics is "pub" providing a user-agent that "action" does not already provide. Why does a user-agent need to know that this link is "publishing"? Arguing that "action" is too generic and therefore useless, is like arguing that an link in HTML is useless because it doesn't tell you what kind of document is being pointed at. We should strive to NOT include semantics that the UA does not need to complete its task. Providing unused semantics just creates useless coupling. Darrel --f46d042ef4a5572e2a04d4acaead Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Jan,

On Fri, Feb 1, 2013 at 11:39 AM, Jan Algermissen <jan= .algermissen@nordsc.com> wrote:

=
So then ... if your UA sees


Link: </foo>; rel=3D"pub";title=3D"Publish"


just display a [Publish] Button.


First, "pub" is not a = valid registered link relation, nor is it valid syntax for an extended link= relation. =A0Second, what additional semantics is "pub" providin= g a user-agent=A0that "action" does not already provide. =A0Why d= oes a user-agent need to know that this link is "publishing"?

Arguing that "action" is too gene= ric and therefore useless, is like arguing that an <a/> link in HTML = is useless because it doesn't tell you what kind of document is being p= ointed at. =A0We should strive to NOT include semantics that the UA does no= t need to complete its task. =A0Providing unused semantics just creates use= less coupling.

Darrel
--f46d042ef4a5572e2a04d4acaead-- From jan.algermissen@nordsc.com Fri Feb 1 10:11:50 2013 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 CE83421E8041 for ; Fri, 1 Feb 2013 10:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_37=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 mMGxTrxx1pSl for ; Fri, 1 Feb 2013 10:11:50 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id EAF0B21E8039 for ; Fri, 1 Feb 2013 10:11:49 -0800 (PST) Received: from [192.168.2.103] (p548F9F56.dip.t-dialin.net [84.143.159.86]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0LtG3f-1UzoKH0QAN-012se6; Fri, 01 Feb 2013 19:11:46 +0100 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: NEW RELATION: action From: Jan Algermissen In-Reply-To: Date: Fri, 1 Feb 2013 19:11:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3F268583-BC18-412F-8348-16AFB070EC21@nordsc.com> References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> <-3128426172162859719@unknownmsgid> <022b01ce0085$a4452b90$eccf82b0$@tavis.ca> <6D2125B5-02DE-4016-86BA-38F8FA100DB4@nordsc.com> To: darrel@tavis.ca X-Mailer: Apple Mail (2.1499) X-Provags-ID: V02:K0:UBnVWePkQG1A2j/CxDj8+iZCbO43UOLxFrEgNDHDO5v zxLMnAD0/kfiBd+fQ5Muez2R6MJpgrsykeemvfHkJ6JAiBZA1B 5O+5IaLkhYK1/41N532Xc1ly+okGqLf98t5EttQYGUQw6ckkrC +EETdAcAAOyTxVooPrzzShhBsmYvvKLpUnB01NLun07KaV3F+p lFcrjyh3tRVWLLOmoDdO2F7cqv8zcySivFCJOmNVUSPOyrSBw4 BtNhj6hygnxlg3/od0Nw5U9KTWkSZw2ZBakLZhuQ8B3MKVd7rx RPr8SknN4dL7YWwajqOnhyzAHjFQIV2470WziBa5kyQSK0K6xe z8HmrNbcZmlda4JropobRN4pT8PkGVwtZTafiY+5/iY6zASHiO Cph2GFEDWbRWQ== Cc: link-relations 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, 01 Feb 2013 18:11:51 -0000 On 01.02.2013, at 18:00, Darrel Miller wrote: >=20 > Jan, >=20 > On Fri, Feb 1, 2013 at 11:39 AM, Jan Algermissen = wrote: >=20 >=20 > So then ... if your UA sees >=20 >=20 > Link: ; rel=3D"pub";title=3D"Publish" >=20 >=20 > just display a [Publish] Button. >=20 >=20 > First, "pub" is not a valid registered link relation, nor is it valid = syntax for an extended link relation. =20 Well, consider it an example :-) > Second, what additional semantics is "pub" providing a user-agent that = "action" does not already provide. Why does a user-agent need to know = that this link is "publishing"? If it does not understand the semantic, why would it POST/PUT to the = target? >=20 > Arguing that "action" is too generic and therefore useless, is like = arguing that an link in HTML is useless because it doesn't tell you = what kind of document is being pointed at. =20 makes sense, because I can allways GET it. 'action' is trying to do the same for POST/PUT ... but no client will = ever traverse that link with a POST/PUT unless it understands the = refinement of the rel (e.g. urn:publish as mentioned) Jan > We should strive to NOT include semantics that the UA does not need to = complete its task. Providing unused semantics just creates useless = coupling. >=20 > Darrel From darrel.miller@gmail.com Fri Feb 1 10:58:53 2013 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 BC43821E8039 for ; Fri, 1 Feb 2013 10:58:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.825 X-Spam-Level: X-Spam-Status: No, score=-2.825 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 9nNc3JdUlrEf for ; Fri, 1 Feb 2013 10:58:52 -0800 (PST) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) by ietfa.amsl.com (Postfix) with ESMTP id 8F15C11E8097 for ; Fri, 1 Feb 2013 10:58:52 -0800 (PST) Received: by mail-lb0-f176.google.com with SMTP id s4so4891841lbc.35 for ; Fri, 01 Feb 2013 10:58:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=TfDEf1DOBrfZgWB0z1PApDUxNA+ZC1G0TPaMs7Zz6U8=; b=smESOxajQDN4fQeY4uTPOfIGwQJ75Saq7QRb1YjAmJ6V1jD8lLezhW1USQffvxlJqE xGAHOUaTjYxVy06gJvSLlXeZpu/f/h6y6trkuseHoyfwGkfjbY/tfP03DQm3TJBKHtpo PaHF6R0YYWXzlfMW7SLjN4FRmO7b/XSvfDQADFpChb327gakds3+pIv7yEhyMM6V5BJU fKnW6YZlhj90vpbe1uDiiDtdLCdi5E1YFb5DZfgc43b/65NW940rjZmN8h1NvUHjDyN2 t99s9fiDPr9kOOOHPs25LYFWs7AXM1uQzjlisq/RhoyEoFciJ1iDpS1queuNRYCaFn2Y K7rg== MIME-Version: 1.0 X-Received: by 10.152.144.130 with SMTP id sm2mr12099967lab.49.1359745131326; Fri, 01 Feb 2013 10:58:51 -0800 (PST) Received: by 10.152.109.204 with HTTP; Fri, 1 Feb 2013 10:58:51 -0800 (PST) In-Reply-To: <3F268583-BC18-412F-8348-16AFB070EC21@nordsc.com> References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> <-3128426172162859719@unknownmsgid> <022b01ce0085$a4452b90$eccf82b0$@tavis.ca> <6D2125B5-02DE-4016-86BA-38F8FA100DB4@nordsc.com> <3F268583-BC18-412F-8348-16AFB070EC21@nordsc.com> Date: Fri, 1 Feb 2013 13:58:51 -0500 Message-ID: Subject: Re: NEW RELATION: action From: Darrel Miller To: Jan Algermissen Content-Type: multipart/alternative; boundary=e89a8f2348a989ad9f04d4ae5595 Cc: link-relations X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: darrel@tavis.ca List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 18:58:53 -0000 --e89a8f2348a989ad9f04d4ae5595 Content-Type: text/plain; charset=ISO-8859-1 Jan, On Fri, Feb 1, 2013 at 1:11 PM, Jan Algermissen wrote: > > makes sense, because I can allways GET it. > > rel="action" makes sense because you can always POST an empty body to it. > 'action' is trying to do the same for POST/PUT ... but no client will ever > traverse that link with a POST/PUT unless it understands the refinement of > the rel (e.g. urn:publish as mentioned) > > I don't understand why you think this. A user-agent will POST to the link if the human driving the user-agent decides they want to do that. The only job of the UA is to provide an affordance that allows the human to make that choice. A user-agent does not have any need to understand what "publish" means any more than a user-agent knows what is happening when they follow a rel="search" link. As long as the UA has sufficient information to be able to activate the link when requested, that is enough. Darrel --e89a8f2348a989ad9f04d4ae5595 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Jan,


On Fri, Feb 1, 2013 at 1:11 PM, Jan Algermissen <jan.= algermissen@nordsc.com> wrote:

<a> makes = sense, because I can allways GET it.

rel=3D"action" makes sense because yo= u can always POST an empty body to it.

=A0
'action' is trying to do the same for POST/PUT ... but no client wi= ll ever traverse that link with a POST/PUT unless it understands the refine= ment of the rel (e.g. urn:publish as mentioned)


I don't understand why you think this. =A0= A user-agent will POST to the link if the human driving the user-agent deci= des they want to do that. =A0The only job of the UA is to provide an afford= ance that allows the human to make that choice. =A0A user-agent does not ha= ve any need to understand what "publish" means any more than a us= er-agent knows what is happening when they follow a rel=3D"search"= ; link. =A0As long as the UA has sufficient information to be able to activ= ate the link when requested, that is enough.


Darrel
=A0
--e89a8f2348a989ad9f04d4ae5595-- From jan.algermissen@nordsc.com Fri Feb 1 11:18:31 2013 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 BB51221F8D67 for ; Fri, 1 Feb 2013 11:18:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_37=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 iBAkfIbh4xkb for ; Fri, 1 Feb 2013 11:18:31 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by ietfa.amsl.com (Postfix) with ESMTP id DE06D21F8D62 for ; Fri, 1 Feb 2013 11:18:30 -0800 (PST) Received: from [192.168.2.103] (p548F9F56.dip.t-dialin.net [84.143.159.86]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0Lgc09-1Un4tM2mnd-00nfnJ; Fri, 01 Feb 2013 20:18:29 +0100 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: NEW RELATION: action From: Jan Algermissen In-Reply-To: Date: Fri, 1 Feb 2013 20:18:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <694EDD73-FAB5-419E-B72D-717F5F7F21BF@nordsc.com> References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> <-3128426172162859719@unknownmsgid> <022b01ce0085$a4452b90$eccf82b0$@tavis.ca> <6D2125B5-02DE-4016-86BA-38F8FA100DB4@nordsc.com> <3F268583-BC18-412F-8348-16AFB070EC21@nordsc.com> To: darrel@tavis.ca X-Mailer: Apple Mail (2.1499) X-Provags-ID: V02:K0:0wTYj7h6Zw9RUcKod9Wgjg6/vqUfHaveLXgWXjthunV bQWDZazxYALg15FtkoxKTBIRIi9Z4ymd9ez2ymdFWZD7qQR9LF dZkRLTedwyjTNo6LTzyITrH+hNO7UOUpfg3dwEYozwdYzr4i9c x6TqvL+LYlMuKAG1V8nar8buWLhvBQtP4RB51NtWQySz3pfSgP NDm53enYeeUWMbbJ+pRIgDF6kvwiHoE8anGeM6syz22mfppG2X kWcbnHLMvDxz35734jqWsV16qFAEfgKCxHHJMYNro1MNad9jhq yl93LrYZiB0obafhxPXamDrBFpt5Bl1XXuPbVcoxzpDslIV4bj PGJ0YXVQGmAcuv4+wHy0TddzmXFETaGBvhCjR1qR+JqvQ25g4q 8JJgtxm7Xb82Q== Cc: link-relations 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, 01 Feb 2013 19:18:31 -0000 On 01.02.2013, at 19:58, Darrel Miller wrote: > Jan, >=20 >=20 > On Fri, Feb 1, 2013 at 1:11 PM, Jan Algermissen = wrote: >=20 > makes sense, because I can allways GET it. >=20 > rel=3D"action" makes sense because you can always POST an empty body = to it. >=20 > =20 > 'action' is trying to do the same for POST/PUT ... but no client will = ever traverse that link with a POST/PUT unless it understands the = refinement of the rel (e.g. urn:publish as mentioned) >=20 >=20 > I don't understand why you think this. A user-agent will POST to the = link if the human driving the user-agent decides they want to do that. I meant automatically. > The only job of the UA is to provide an affordance that allows the = human to make that choice. A user-agent does not have any need to = understand what "publish" means any more than a user-agent knows what is = happening when they follow a rel=3D"search" link. As long as the UA has = sufficient information to be able to activate the link when requested, = that is enough. Yes - and for that you do not need 'action'. Jan >=20 >=20 > Darrel > =20 From ioseb.dzmanashvili@gmail.com Fri Feb 1 11:40:44 2013 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 A842D21F8ECE for ; Fri, 1 Feb 2013 11:40:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.766 X-Spam-Level: X-Spam-Status: No, score=-2.766 tagged_above=-999 required=5 tests=[AWL=-0.368, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, J_CHICKENPOX_73=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 MNgj69+LJqwH for ; Fri, 1 Feb 2013 11:40:43 -0800 (PST) Received: from mail-ea0-f170.google.com (mail-ea0-f170.google.com [209.85.215.170]) by ietfa.amsl.com (Postfix) with ESMTP id 6C53B21F846E for ; Fri, 1 Feb 2013 11:40:43 -0800 (PST) Received: by mail-ea0-f170.google.com with SMTP id a11so1870536eaa.15 for ; Fri, 01 Feb 2013 11:40:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:message-id:in-reply-to:references :subject:x-mailer:mime-version:content-type; bh=Z6UI994dqbSzhwe3BweEMfvrvt27xj37rzWNi3BlR8A=; b=svcU31RjRgvp5Fr7fnoYYXcyuqy170wzSw3oeJLzxEL+dGIi7g/1ZO9Cfm27YEYEll YyZdR7HDuao1e1GFstF08LGZMyLvWkXmdyoN1TSFDR4BVMCqR4AI53hEs2kOyVyw7PMY Kp4xrzhrkjVyunTREgToNdyOUprhWu2mn4F2f2sZPYkYs01y2dXTwNauCjCEPLgHn2jU MRZeU+GbCrtDH2+3yRogb8NYqk8CT3pIjLq+M9STN8q38CEkDcdMD6jrEpnNeu6dSuGC D156z9esrxZc6fQatx5zgV/RtJI4LNwtkASC44Hu6DSMHz2TEkZYqn4fieVJV6e+RFO6 seiw== X-Received: by 10.14.206.132 with SMTP id l4mr42542147eeo.38.1359747642580; Fri, 01 Feb 2013 11:40:42 -0800 (PST) Received: from [192.168.1.3] ([176.73.174.236]) by mx.google.com with ESMTPS id 46sm14053089eeg.4.2013.02.01.11.40.39 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 01 Feb 2013 11:40:41 -0800 (PST) Date: Fri, 1 Feb 2013 23:40:40 +0400 From: Ioseb Dzmanashvili To: Markus Lanthaler Message-ID: <5201FC093217400AADB1290FE3468BA3@gmail.com> In-Reply-To: <510be91a.41c70e0a.627b.ffffee6eSMTPIN_ADDED_BROKEN@mx.google.com> References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> <510ba796.09df0e0a.3a70.fffff0f4SMTPIN_ADDED_BROKEN@mx.google.com> <084F8A1FB98040A1BD1B987D3CF3D518@gmail.com> <9090DD8D497247E7BD1C3FE30231A0CC@gmail.com> <510be91a.41c70e0a.627b.ffffee6eSMTPIN_ADDED_BROKEN@mx.google.com> Subject: Re: NEW RELATION: action X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="510c1a38_127e6585_28a" Cc: darrel@tavis.ca, mca , 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: Fri, 01 Feb 2013 19:40:44 -0000 --510c1a38_127e6585_28a Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Markus, > MAY means that it's not required. If it's not required, what does such a link mean if there isn't any other information? Yes, "MAY" mean that it's not required but states that it's possible and there is a way to add additional meaning to the link without redefining "action" semantics each time like: "hey, here i have my custom link relation urn:boa:boa:publish" and just send POST request to me without body if you want to publish this piece of content". This is one of the purposes of the "action" relation type. > There's nothing wrong with a second rel. It's also true that consumers need to recognize the token to do something useful. The problem is that the "action" rel just says, you can POST to this URL, if you do so, you SHOULD not include a body in your POST. Yes "action" says exactly this and it is absolutely enough for application code: to recognise actions in the representation; render these actions as buttons(or whatever else); and if user chooses one of them just send POST requests to the URI without making any assumptions. > So, in a user facing app, what does this mean: OK? As of current state of the draft nothing special. As i already mentioned in previous emails behaviour for "GET" request is not defined(and i think discussions are for such purposes to make specs clear). But: * we have forms in HTML and instead of using "action" links it's possible to embed form + multiple action buttons which after rendering will make clear for users what to do next. * I'd ask what what does this link means: Stylesheet? here is how it solved in HTML spec [1] there is restriction: "The stylesheet (http://www.w3.org/TR/html5/links.html#link-type-stylesheet) keyword may be used with link (http://www.w3.org/TR/html5/document-metadata.html#the-link-element) elements. This keyword creates an external resource link (http://www.w3.org/TR/html5/links.html#external-resource-link) that contributes to the styling processing model (http://www.w3.org/TR/html5/document-metadata.html#styling)." * There are other media formats can benefit from "action" link relation and HTML is not absolute must. * It makes perfect sense when used in a Link header. > What I'm trying to say is, that basically all the information is in the "OK" (well, in this case it isn't) and not in "action". Maybe it's also just that action is irritating me. I definitely find it too generic and overloaded. Perhaps something like "ping" (which itself is also quite overloaded) might work better. Just an idea. I do not get how "ping" is related. [1] http://www.w3.org/TR/html5/links.html#link-type-stylesheet Cheers, ioseb On Friday, February 1, 2013 at 8:10 PM, Markus Lanthaler wrote: > On Friday, February 01, 2013 4:47 PM , Ioseb Dzmanashvili wrote: > > > There is no need to to infer something from the target URI or use something else. > > Draft states that: "Actual function to be performed by the server, MAY be > > advertised by including an extension link relation types as defined per Section 4.2 > > of [RFC5988]." > > > > > MAY means that it's not required. If it's not required, what does such a link mean if there isn't any other information? > > > > I do not get what is wrong with second rel? There are bunch of link relations > > which doesn't add any value to M2M interaction unless participant(s) are > > trained correspondingly. > > > > > There's nothing wrong with a second rel. It's also true that consumers need to recognize the token to do something useful. The problem is that the "action" rel just says, you can POST to this URL, if you do so, you SHOULD not include a body in your POST. > > > > > AFAICS, you cannot do anything useful with just rel="action". > > > > I do not agree. a) The relation works perfectly in applications > > where user interaction exists and there is no need for defining > > additional semantics; > > and b) as i noted above spec clearly says how to extend it's > > meaning. > > > > > So, in a user facing app, what does this mean: OK? > > What I'm trying to say is, that basically all the information is in the "OK" (well, in this case it isn't) and not in "action". Maybe it's also just that action is irritating me. I definitely find it too generic and overloaded. Perhaps something like "ping" (which itself is also quite overloaded) might work better. Just an idea. > > > > -- > Markus Lanthaler > @markuslanthaler > > --510c1a38_127e6585_28a Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Markus,

> MAY means= that it's not required. If it's not required, what does such a link mean= if there isn't any other information=3F

Yes, =22= MAY=22 mean that it's not required but states that it's possible and ther= e is a way to add additional meaning to the link without redefining =22ac= tion=22 semantics each time like: =22hey, here i have my custom link rela= tion urn:boa:boa:publish=22 and just send POST request to me without body= if you want to publish this piece of content=22. This is one of the purp= oses of the =22action=22 relation type. 

&g= t; There's nothing wrong with a second rel. It's also true that cons= umers need to recognize the token to do something useful. The problem is = that the =22action=22 rel just says, you can POST to this URL, if you do = so, you SHOULD not include a body in your POST.

= Yes =22action=22 says exactly this and it is absolutely enough for applic= ation code: to recognise actions in the representation; render these acti= ons as buttons(or whatever else); and if user chooses one of them just se= nd POST requests to the URI without making any assumptions.
> So, in a user facing app, what does this mean: <a hre= f=3D=22http://example.com/dlfkj=22 rel=3D=22action=22>OK</a>=3F<= /div>

As of current state of the draft nothing special= . As i already mentioned in previous emails behaviour for =22GET=22 reque= st is not defined(and i think discussions are for such purposes to make s= pecs clear). But:

* we have forms in HTML and in= stead of using =22action=22 links it's possible to embed form + multiple = action buttons which after rendering will make clear for users what to do= next.
* I'd ask what what does this link means: <a href=3D=22= /resource=22 rel=3D=22stylesheet=22>Stylesheet</a>=3F here is ho= w it solved in HTML spec =5B1=5D there is restriction: =22The stylesheet&n= bsp;keyword may be used with link elements. This keyword creates an external resource l= ink&nb= sp;that contributes to the styling processing mod= el.=22=
* There are other media formats can benefit from =22act= ion=22 link relation and HTML is not absolute must.
* It makes = perfect sense when used in a Link header.

>&n= bsp;What I'm trying to say is, that basically all the information is in t= he =22OK=22 (well, in this case it isn't) and not in =22action=22. Maybe = it's also just that action is irritating me. I definitely find it too gen= eric and overloaded. Perhaps something like =22ping=22 (which itself is a= lso quite overloaded) might work better. Just an idea.

I do not get how =22ping=22 is related.


Cheers,
ioseb
=20

On =46riday, =46ebruar= y 1, 2013 at 8:10 PM, Markus Lanthaler wrote:

On =46riday, =46ebruary 01, 2013= 4:47 PM , Ioseb Dzmanashvili wrote:

There is no need to to infer something from the t= arget URI or use something else.
Draft states that: =22Actual f= unction to be performed by the server, MAY be
advertised by inc= luding an extension link relation types as defined per Section 4.2
<= div>of =5BR=46C5988=5D.=22

MA= Y means that it's not required. If it's not required, what does such a li= nk mean if there isn't any other information=3F

=
I do not get what is wr= ong with second rel=3F There are bunch of link relations
which = doesn't add any value to M2M interaction unless participant(s) are
<= div>trained correspondingly.

= There's nothing wrong with a second rel. It's also true that consumers ne= ed to recognize the token to do something useful. The problem is that the= =22action=22 rel just says, you can POST to this URL, if you do so, you = SHOULD not include a body in your POST.


A= =46AICS, you cannot do anything useful with just rel=3D=22action=22.

I do not agree. a) The relation works p= erfectly in applications
where user interaction exists and ther= e is no need for defining
additional semantics;
and b= ) as i noted above spec clearly says how to extend it's
meaning= .

So, in a user facing app, w= hat does this mean: <a href=3D=22http://example.com/dlfkj=22 rel=3D=22action=22>OK</a>=3F=

What I'm trying to say is, that basically all t= he information is in the =22OK=22 (well, in this case it isn't) and not i= n =22action=22. Maybe it's also just that action is irritating me. I defi= nitely find it too generic and overloaded. Perhaps something like =22ping= =22 (which itself is also quite overloaded) might work better. Just an id= ea.



--
M= arkus Lanthaler
=40markuslanthaler
=20 =20 =20 =20 =20

--510c1a38_127e6585_28a-- From jan.algermissen@nordsc.com Fri Feb 1 12:24:02 2013 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 4073721E8050 for ; Fri, 1 Feb 2013 12:24:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.049 X-Spam-Level: X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[AWL=0.200, 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 o-VV9y63WHud for ; Fri, 1 Feb 2013 12:24:01 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id 1C07721E8041 for ; Fri, 1 Feb 2013 12:24:01 -0800 (PST) Received: from [192.168.2.103] (p548F9F56.dip.t-dialin.net [84.143.159.86]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0MBZ3e-1U9aMU3oQg-00AcKz; Fri, 01 Feb 2013 21:23:57 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: NEW RELATION: action From: Jan Algermissen In-Reply-To: <694EDD73-FAB5-419E-B72D-717F5F7F21BF@nordsc.com> Date: Fri, 1 Feb 2013 21:23:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> <-3128426172162859719@unknownmsgid> <022b01ce0085$a4452b90$eccf82b0$@tavis.ca> <6D2125B5-02DE-4016-86BA-38F8FA100DB4@nordsc.com> <3F268583-BC18-412F-8348-16AFB070EC21@nordsc.com> <694EDD73-FAB5-419E-B72D-717F5F7F21BF@nordsc.com> To: darrel@tavis.ca X-Mailer: Apple Mail (2.1499) X-Provags-ID: V02:K0:pXMou1fG8Ur9qKqM3vCg3pwekMpcxRGOrmEIOmux+Fd fTr7RfMp/J/VNfS4S8nPA0ibzHdaH9Dd9JW40pg0v8kMIIDS3B qU7NvpjDBZTbxdRSVyhZV01Tv5DUhf1519UCNVcUPNwvf6Jcua c7mCpoHH5UPWb3/A+uGSH0DwSZj/T005TDQWn6marM0yvn1AXk yzkfZQYQCZQCzLCA+V3aIIfcAHLkltpl6jYzc7JY60FXuEaWwT LStF6UhC+9FpdfS/w6kuw8uGjXmlyMw22c5ZgvOLMb8fiNmFVv oN8SJkyJmfYmaqrvKb5jDGRl0C42mC8wUzgkSz2r7sqpsSsqck vSfSmmnfqbzDDhNPR+VHOs7BgnU/9WGnVWU6OPJN5nLSS3KFK1 YujPaSdF8QlJQ== Cc: link-relations 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, 01 Feb 2013 20:24:02 -0000 On 01.02.2013, at 20:18, Jan Algermissen = wrote: >=20 > On 01.02.2013, at 19:58, Darrel Miller = wrote: >=20 >=20 >=20 >> The only job of the UA is to provide an affordance that allows the = human to make that choice. A user-agent does not have any need to = understand what "publish" means any more than a user-agent knows what is = happening when they follow a rel=3D"search" link. As long as the UA has = sufficient information to be able to activate the link when requested, = that is enough. >=20 > Yes - and for that you do not need 'action'. In addition: since you cannot specifiy the kind of payload to send, = 'action' really only manifests the (anti-)pattern of action resources. What you really want is something like an inline form to specify the = payload. And this is where it gets interesting, because Ioseb has = recently registered the (very valuable) edit-form and ceate-form = relations. So, why not use that one and render a button for it. Upon clicking the = button, the client can download the form, display an overlay to enter = the data and present a 'send' button.? The link title will make for a fine button label. Link: ; rel=3D"edit-form"; title=3D"Update customer data" Link: ; rel=3D"create-form"; title=3D"Initiate new workflow" Jan >=20 > Jan >=20 >=20 >>=20 >>=20 >> Darrel >>=20 >=20 > _______________________________________________ > link-relations mailing list > link-relations@ietf.org > https://www.ietf.org/mailman/listinfo/link-relations From ioseb.dzmanashvili@gmail.com Fri Feb 1 12:27:17 2013 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 2625E21F8835 for ; Fri, 1 Feb 2013 12:27:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.574 X-Spam-Level: X-Spam-Status: No, score=-0.574 tagged_above=-999 required=5 tests=[AWL=-2.376, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_84=0.6, J_CHICKENPOX_91=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 dHGpCcbve8EW for ; Fri, 1 Feb 2013 12:27:12 -0800 (PST) Received: from mail-ea0-f178.google.com (mail-ea0-f178.google.com [209.85.215.178]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8DD21F8488 for ; Fri, 1 Feb 2013 12:27:11 -0800 (PST) Received: by mail-ea0-f178.google.com with SMTP id a14so1959845eaa.23 for ; Fri, 01 Feb 2013 12:27:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:message-id:in-reply-to:references :subject:x-mailer:mime-version:content-type; bh=BXirSrjFkhOPYtrGH+kg7bajjIr+zP3LwiPNAgHIkWY=; b=BGTADNfbOPH1fOi/ktwWzgKOBADOjViooAtULSrmhaM9WfAbmqVcif/tEdsZtQCEy/ MlVBq4UgljTMP/dKeNs29cnL+JKA03rVHNf8hHQ0Hc8LDrE09y3g40BrYocI8Q/EGqCz f9pEKTIahxb08Z1YTVtU2bVUE6dLWCfSYa81t6hxf/05w7nyHpuXSDb9feEIc8BW3o1w cEvIckmqZxi96RX6//uBq+4eUI8Y0jIbPGrlVtS5tiqQdwZc+8ZqGG8T3Bres5jVDjBV 3hJhkm4k5KiJMOz1KyWiHbQNrPxcuIjK2UbViA/jIcSBtcux7ovdAQYMIRs0QABhJ82n /2xg== X-Received: by 10.14.177.1 with SMTP id c1mr43414834eem.8.1359750428289; Fri, 01 Feb 2013 12:27:08 -0800 (PST) Received: from [192.168.1.3] ([176.73.174.236]) by mx.google.com with ESMTPS id h5sm14237650eem.1.2013.02.01.12.27.05 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 01 Feb 2013 12:27:06 -0800 (PST) Date: Sat, 2 Feb 2013 00:27:04 +0400 From: Ioseb Dzmanashvili To: Jan Algermissen Message-ID: In-Reply-To: References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> <01a701ce006f$ad6aa3a0$083feae0$@lanthaler@gmx.net> Subject: Re: NEW RELATION: action X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="510c2518_1094d84e_28a" Cc: darrel@tavis.ca, mca , 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: Fri, 01 Feb 2013 20:27:17 -0000 --510c2518_1094d84e_28a Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Jan, > For the sake of displaying a button: this can always be done if there is a title in the link. The argument doesn't stand. For example: Link: ; title="Do Something" doesn't imply that it must be rendered as a button nor behave like action which is required to send POST request to the server. It's just a link nothing more. Agents may only assume that they can fetch it. But: Link: ; rel="action" title="Do Something" already has enough semantics(i mean if "action" link is already defined and known for agents) and it clearly mean that it can be rendered as an action button which MUST(or SHOULD) send POST request to the server. > 'action' is trying to do the same for POST/PUT ... but no client will ever traverse that link with a POST/PUT unless it understands the refinement of the rel (e.g. urn:publish as mentioned) This passage makes me think that whole world of URIs/HTTP works without interventions and everything is traversed by some mysterious automated agents :-) if agents are automated, they must be taught to recognise registered link relations types at least. I do not think that any automated agent "traverses" HTML forms(or other forms) unless they are taught to do so(i assume someone provides agent with input and agent recognises something and does something etc...) >> The only job of the UA is to provide an affordance that allows the human to make that choice. A user-agent does not have >> any need to understand what "publish" means any more than a user-agent knows what is happening when they follow a >> rel="search" link. As long as the UA has sufficient information to be able to activate the link when requested, that is enough. > Yes - and for that you do not need 'action'. Okay, i'll ask a question. I'm working on an application(native app) which is used for monitoring services infrastructure. In this application i've several actions and "restart" and "suspend" are two of them. These actions are for application users(people). Now i've dilemma to solve this problem. One way i come up with is the "action" link relation. In practice this looks like this: > GET /service HTTP/1.1 > Host: domain.org < HTTP/1.1 200 OK < Content-Type: ... < Content-Length: ... < Link: ; rel="action"; title="Restart", < ; rel="action"; title="Suspend" < < [BODY HERE] This message is enough for program to: a) render information on the screen; b) determine actions with implied semantics: "just POST to this URI" and expose these actions to user. Now my questions are: 1) What is wrong with this approach (other than automated agents couldn't traverse these links)? 2) How could links without rel="action" help me? 3) How it would be better if i defined two separate custom relations: "urn:restart" and "urn:suspend". 4) What is violated(REST, Web Linking rfc? HTTP protocol?) P.S. I understand M2M concerns, though i do not get the fact that M2M is considered superior over "user->app->service" interaction and especially that all APIs(call it RESTful, Hypermedia or WebAPI) in the world must be blindly traversable from start to end. P.P.S. Could you please CC me in your and Darrel's discussion? I'm not receiving these messages unfortunately. Cheers, Ioseb On Friday, February 1, 2013 at 8:32 PM, Jan Algermissen wrote: > > On 01.02.2013, at 12:31, "Markus Lanthaler" wrote: > > > On Friday, February 01, 2013 10:45 AM, Ioseb Dzmanashvili wrote: > > > > > > To me this smells a lot like a (REST-) anti pattern. > > > > > > I do not agree. Which REST constraint is violated in this case? > > > Using POST without body is valid and "action" links expose > > > availability of actions which may be performed: > > > > > > * without knowing media type; > > > * without need to construct whole message(to conform PUT's > > > replace semantics); > > > * no need to use PATCH > > > * "action" links can be filtered by client and displayed to > > > user(and here we do not even need additional link relation > > > extensions) > > > > > > > > > The problem is they can just be filtered by clients who know about them. How would a generic crawler know it has to avoid those action links? For example, looking at your example: > > > > > > < HTTP/1.1 200 OK > > < Content-Type: ... > > < Content-Length: ... > > < Link: ; rel="action urn:restart"; title="Restart" > > > > Imagine that the link would be embedded in a HTML page: > > > > Restart > > > > What would happen if a crawler follows that link? > > > That is another concern, but a GET should be save anyhow - eh? > > Jan > > > > Would the service be restarted? Assuming that you say links with this relation type just accept POST (and I think that's what Jan was concerned about because it wasn't clear in your initial mail), would it result in an error because it uses GET? > > > > > > On Friday, February 1, 2013 at 4:31 AM, Darrel Miller wrote: > > > > > Yes there are other ways of doing this, but I can't see any > > > negative impacts on the system by using this approach. > > > > > > [..] > > > > > > The huge benefit in my mind of this link relation is that it > > > opens the door for generic clients to be able to start doing > > > some simple write operations. > > > > > > > > > Talking about HTML, how is that different from using an empty form (just submit button) and @method=POST? > > > > > > > > > > -- > > Markus Lanthaler > > @markuslanthaler > > > > > --510c2518_1094d84e_28a Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Jan, 

> =46or = the sake of displaying a button: this can always be done if there is a ti= tle in the link.

The argument doesn't stand. =46= or example:

Link: </some/resource>; title=3D= =22Do Something=22 

doesn't imply that it m= ust be rendered as a button nor behave like action which is required to s= end POST request to the server. It's just a link nothing more. Agents may= only assume that they can fetch it. But:

Link: = </some/resource>; rel=3D=22action=22 title=3D=22Do Something=22&nbs= p;

already has enough semantics(i mean if =22act= ion=22 link is already defined and known for agents) and it clearly mean = that it can be rendered as an action button which MUST(or SHOULD) send PO= ST request to the server.

> 'action' is tryin= g to do the same for POST/PUT ... but no client will ever traverse that l= ink with a POST/PUT unless it understands the refinement of the rel (e.g.= urn:publish as mentioned)

This passage makes me= think that whole world of URIs/HTTP works without interventions and ever= ything is traversed by some mysterious automated agents :-) if agents are= automated, they must be taught to recognise registered link relations ty= pes at least. I do not think that any automated agent =22traverses=22 HTM= L forms(or other forms) unless they are taught to do so(i assume someone = provides agent with input and agent recognises something and does somethi= ng etc...)

>> The only job of the UA is to= provide an affordance that allows the human to make that choice.  A= user-agent does not have 
>> any need to understand= what =22publish=22 means any more than a user-agent knows what is happen= ing when they follow a 
>> rel=3D=22search=22 link. =  As long as the UA has sufficient information to be able to activate= the link when requested, that is enough.
> Yes - and for th= at you do not need 'action'.

Okay, i'll ask a qu= estion. I'm working on an application(native app) which is used for monit= oring services infrastructure. In this application i've several actions a= nd =22restart=22 and =22suspend=22 are two of them. These actions are for= application users(people). Now i've dilemma to solve this problem. One w= ay i come up with is the =22action=22 link relation. In practice this loo= ks like this:

> GET /service HTTP/1.1
> Host: domain.org

< HTTP/1.1 200 OK
< Content-Type: ...
< Content-Length: ...
< Link: </service/restarter>; rel=3D=22action=22; title=3D=22= Restart=22,
<       </service/suspender>= ;; rel=3D=22action=22; title=3D=22Suspend=22
< 
< =5BBODY HERE=5D

This message is enough f= or program to: a) render information on the screen; b) determine actions = with implied semantics: =22just POST to this URI=22 and expose these acti= ons to user. Now my questions are:

1) What is wr= ong with this approach (other than automated agents couldn't traverse the= se links)=3F
2) How could links without rel=3D=22action=22 help= me=3F
3) How it would be better if i defined two separate cust= om relations: =22urn:restart=22 and =22urn:suspend=22.
4) What = is violated(REST, Web Linking rfc=3F HTTP protocol=3F)

P.S.
I understand M2M concerns, though i do not get the = fact that M2M is considered superior over =22user->app->service=22 = interaction and especially that all APIs(call it RESTful, Hypermedia or W= ebAPI) in the world must be blindly traversable from start to end.
<= div>
P.P.S.
Could you please CC me in your and Da= rrel's discussion=3F I'm not receiving these messages unfortunately. = ;

Cheers,
Ioseb
=20

On =46riday, =46ebruar= y 1, 2013 at 8:32 PM, Jan Algermissen wrote:


On 01.02.2013, at= 12:31, =22Markus Lanthaler=22 <markus.lanthaler=40gmx.net> wrote:

=
On =46riday, =46ebruary 01, 2013 = 10:45 AM, Ioseb Dzmanashvili wrote:

To me this smells a lo= t like a (REST-) anti pattern.

I do= not agree. Which REST constraint is violated in this case=3F
U= sing POST without body is valid and =22action=22 links expose
a= vailability of actions which may be performed:

= * without knowing media type;
* without need to construct whole= message(to conform PUT's
replace semantics);
* no n= eed to use PATCH
* =22action=22 links can be filtered by clien= t and displayed to
user(and here we do not even need additional= link relation
extensions)

The problem is they can just be filtered by clients who know abou= t them. How would a generic crawler know it has to avoid those action lin= ks=3F =46or example, looking at your example:

< HTTP/1.1 200 OK
< Content-Type: ...
<= div>< Content-Length: ...
< Link: </service/manager>= ;; rel=3D=22action urn:restart=22; title=3D=22Restart=22

Imagine that the link would be embedded in a HTML page:

<a href=3D=22/service/manager=22 rel=3D=22action urn:= restart=22>Restart</a>

What would happe= n if a crawler follows that link=3F


That is another concern, but a GET should be save a= nyhow - eh=3F

Jan


<= /div>
Would the service be restart= ed=3F Assuming that you say links with this relation type just accept POS= T (and I think that's what Jan was concerned about because it wasn't clea= r in your initial mail), would it result in an error because it uses GET=3F=


On =46riday, =46ebruary 1, 2013 = at 4:31 AM, Darrel Miller wrote:

Yes there are other ways of doing this, but I can't see= any
negative impacts on the system by using this approach.

=5B..=5D

The huge benefit = in my mind of this link relation is that it
opens the door for = generic clients to be able to start doing
some simple write ope= rations.

Talking about HTM= L, how is that different from using an empty form (just submit button) an= d =40method=3DPOST=3F



<= div>
--
Markus Lanthaler
=40markuslanth= aler
=20 =20 =20 =20 =20

--510c2518_1094d84e_28a-- From jan.algermissen@nordsc.com Fri Feb 1 12:41:50 2013 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 D440E21F904A for ; Fri, 1 Feb 2013 12:41:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.150, 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 bqAZnzZxkbcv for ; Fri, 1 Feb 2013 12:41:50 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by ietfa.amsl.com (Postfix) with ESMTP id 2E71321F9049 for ; Fri, 1 Feb 2013 12:41:50 -0800 (PST) Received: from [192.168.2.103] (p548F9F56.dip.t-dialin.net [84.143.159.86]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0MYcDK-1UWmMh00xe-00VYvG; Fri, 01 Feb 2013 21:41:49 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: NEW RELATION: action From: Jan Algermissen In-Reply-To: Date: Fri, 1 Feb 2013 21:41:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <194C0630-AEAB-4788-A48E-CF425FC2D95F@nordsc.com> References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> <01a701ce006f$ad6aa3a0$083feae0$@lanthaler@gmx.net> To: Ioseb Dzmanashvili X-Mailer: Apple Mail (2.1499) X-Provags-ID: V02:K0:0AuqdyZm4yL6mKVtnmS3jVfLab3n/pkEUcjXaMP1m2S UFKnV/bnIsJ4ygiwKSkPivr4bS7nC00hzb8UQ0czDPbQxa0H9e o3y4AJMJIEtYvD9RyhKlkorA3Vf6c5E8Ny3Ud6FuE1S+kin0n3 A0eV1eQfAkdq0YgDSdGeMT2f2WTnLIF5JRBY4RSRZGC+MBaIwF ObrutkaEPx1Hh9uPxrg7asM1e/JQafrMrp8SdSHPNzUaFRDu8d nMHPW6SB3F3+3c7v9Itq24g27aIp0I4kjqoE/89+ZsAHW8i0hA kQ7x2f15pbMi8G9LRh2AWFw4LHK6qFNLU0g+N9Dad+2i2GUlNn YCvkvmdFIUFpEMO31wk4CGcwCOyPa7gJhLGFe/2bUkQlIWSUJ8 aIXxcfIJfF+VQ== Cc: darrel@tavis.ca, mca , 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: Fri, 01 Feb 2013 20:41:50 -0000 On 01.02.2013, at 21:27, Ioseb Dzmanashvili = wrote: > These actions are for application users(people). If the end user is human ... why not use HTML? Jan From darrel.miller@gmail.com Fri Feb 1 12:43:14 2013 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 C37F721F9049 for ; Fri, 1 Feb 2013 12:43:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.168 X-Spam-Level: X-Spam-Status: No, score=-3.168 tagged_above=-999 required=5 tests=[AWL=0.430, 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 rxcjiWiCQy88 for ; Fri, 1 Feb 2013 12:43:14 -0800 (PST) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) by ietfa.amsl.com (Postfix) with ESMTP id E700421F8A77 for ; Fri, 1 Feb 2013 12:43:12 -0800 (PST) Received: by mail-lb0-f178.google.com with SMTP id n1so4968749lba.37 for ; Fri, 01 Feb 2013 12:43:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=uIXGAZLLnwP/9Z+cDFMo4G7kkaz5m3cbJG5wvA0IXEY=; b=MQ3lAWTDz1Xcws7jB6waNgoRxKe2OQoUn2jouNV/WTEJhYIY1MMkfC07h0a9bHpJzH aqbXzyJl+EFKhDubCInF/VMWMzQ/TgRBR9wP3p/yOi0xRH2RHOqCrdUASliWANByYwm0 V8vijCs7h2Cc4KdnfatXrYEFri4qaTmDuS8ZUKgWqoPcd6YDHeGqhglKOGnrsfIrpGEH kChIzLzKWOLII5RVu7VLK/ElqSBcEL2GbiZAGlW7TrULFy673KpYxiMpG7kEXGxl2e0V XWiOECwBb1qrPloUdxnJY/tz64FsUTmWuRAZ/nogLnVq3misOHuIo+4Mz6GF3DQg3HIr AUTw== MIME-Version: 1.0 X-Received: by 10.112.99.197 with SMTP id es5mr5295746lbb.30.1359751388754; Fri, 01 Feb 2013 12:43:08 -0800 (PST) Received: by 10.152.109.204 with HTTP; Fri, 1 Feb 2013 12:43:08 -0800 (PST) In-Reply-To: References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> <-3128426172162859719@unknownmsgid> <022b01ce0085$a4452b90$eccf82b0$@tavis.ca> <6D2125B5-02DE-4016-86BA-38F8FA100DB4@nordsc.com> <3F268583-BC18-412F-8348-16AFB070EC21@nordsc.com> <694EDD73-FAB5-419E-B72D-717F5F7F21BF@nordsc.com> Date: Fri, 1 Feb 2013 15:43:08 -0500 Message-ID: Subject: Re: NEW RELATION: action From: Darrel Miller To: Jan Algermissen , Ioseb Dzmanashvili Content-Type: multipart/alternative; boundary=f46d040172718273ed04d4afca1b Cc: link-relations X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: darrel@tavis.ca List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 20:43:14 -0000 --f46d040172718273ed04d4afca1b Content-Type: text/plain; charset=ISO-8859-1 Jan, On Fri, Feb 1, 2013 at 3:23 PM, Jan Algermissen wrote: > >> The only job of the UA is to provide an affordance that allows the > human to make that choice. A user-agent does not have any need to > understand what "publish" means any more than a user-agent knows what is > happening when they follow a rel="search" link. As long as the UA has > sufficient information to be able to activate the link when requested, that > is enough. > > > > Yes - and for that you do not need 'action'. > > Without "action" a user-agent does not know that it should POST with an empty body. > In addition: since you cannot specifiy the kind of payload to send, > 'action' really only manifests the (anti-)pattern of action resources. > > What you really want is something like an inline form to specify the > payload. And this is where it gets interesting, because Ioseb has recently > registered the (very valuable) edit-form and ceate-form relations. > > So, does this example meet your constraints? > POST /myservice > Content-type: application/x-www-urlencoded-form > action=restart I don't see how this is more self-descriptive. Just because I created a payload, why is that now magically kosher. create-form and edit-form are great, but what about when I'm not creating or editing resources? > So, why not use that one and render a button for it. Upon clicking the > button, the client can download the form, display an overlay to enter the > data and present a 'send' button.? > > Because there is no data to send. The entire UI interaction is _pressing_ the button. Let me provide a visual example http://demo.presscoders.com/designfolio/files/2012/04/launchButton-logo-big.jpg :-) Darrel --f46d040172718273ed04d4afca1b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Jan,


On Fri, Feb 1, 2013 at 3:23 PM, Jan Algermissen <jan.= algermissen@nordsc.com> wrote:
>> The only job of the UA is to pr= ovide an affordance that allows the human to make that choice. =A0A user-ag= ent does not have any need to understand what "publish" means any= more than a user-agent knows what is happening when they follow a rel=3D&q= uot;search" link. =A0As long as the UA has sufficient information to b= e able to activate the link when requested, that is enough.
>
> Yes - and for that you do not need 'action'.


Without "action"= a user-agent does not know that it should POST with an empty body.

=A0
In addition: since you cannot specifiy the kind of payload to send, &= #39;action' really only manifests the (anti-)pattern of action resource= s.

What you really want is something like an inline form to specify the payloa= d. And this is where it gets interesting, because Ioseb has recently regist= ered the (very valuable) edit-form and ceate-form relations.


So, does this example meet your = constraints?


> POST = /myservice
> Content-type: application/x-www-urlencoded-= form
> action=3Drestart

I don= 't see how this is more self-descriptive. =A0Just because I created a p= ayload, why is that now magically kosher.

create-form and edit-form are great, but what about when I'm not creati= ng or editing resources?


=A0
So, why not use that one and render a button for it. Upon clicking the butt= on, the client can download the form, display an overlay to enter the data = and present a 'send' button.?


Because there is no data t= o send. =A0The entire UI interaction is _pressing_ the button.
Let me provide a visual example =A0


:-)

Darrel
=A0
--f46d040172718273ed04d4afca1b-- From ioseb.dzmanashvili@gmail.com Fri Feb 1 12:43:47 2013 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 7427721F8FD5 for ; Fri, 1 Feb 2013 12:43:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=0.799, 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 Mq2bg7fC3xFZ for ; Fri, 1 Feb 2013 12:43:46 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB8221F8A77 for ; Fri, 1 Feb 2013 12:43:46 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id l10so2298250eei.17 for ; Fri, 01 Feb 2013 12:43:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:message-id:in-reply-to:references :subject:x-mailer:mime-version:content-type; bh=Vz3Nk3B9WTlSGFa9VmWnZdBAQwEccJZxgCLV6ecD9lg=; b=wCVb4VVw18HPxIbsuvqBTdGnJdg1RdpSI4elipQKCNXmccBKD1UsPjCYncC7AW3Guz Vxui0CPcs3oPwM+zlfd8fZg5GwBaS87PAdrRfvJ19oyi1KJprlkwF56QRsI6NYicgNml /M6GJ2Tp2kbz4ffFDseuLQWmZUC/BfGkwabT7IUeQ3bU29zX3vvT0aKULOV9VDry7hd6 6QY2brdI4kKjeuEV+wquitKvMzHgpFdWGP8uHqTPm4wOd1DndR5Ox5NmHauwQTcgnP78 LrxQcBgczngA3KHzgDDpOv70O+dPvpc174mmoiXY4JXjBvoq3hCS9sig3gdtamJWxK5o Popg== X-Received: by 10.14.198.198 with SMTP id v46mr43352377een.4.1359751425500; Fri, 01 Feb 2013 12:43:45 -0800 (PST) Received: from [192.168.1.3] ([176.73.174.236]) by mx.google.com with ESMTPS id f49sm14273747eep.12.2013.02.01.12.43.42 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 01 Feb 2013 12:43:43 -0800 (PST) Date: Sat, 2 Feb 2013 00:43:42 +0400 From: Ioseb Dzmanashvili To: Jan Algermissen Message-ID: <8EE9A04051C4412BAA4A769431B6CD5A@gmail.com> In-Reply-To: <194C0630-AEAB-4788-A48E-CF425FC2D95F@nordsc.com> References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> <01a701ce006f$ad6aa3a0$083feae0$@lanthaler@gmx.net> <194C0630-AEAB-4788-A48E-CF425FC2D95F@nordsc.com> Subject: Re: NEW RELATION: action X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="510c28fe_60cd4385_28a" Cc: darrel@tavis.ca, mca , 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: Fri, 01 Feb 2013 20:43:48 -0000 --510c28fe_60cd4385_28a Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Jan, > If the end user is human ... why not use HTML? In this particular case it's an Obj-C App. It's not an HTML app. ioseb On Saturday, February 2, 2013 at 12:41 AM, Jan Algermissen wrote: > > On 01.02.2013, at 21:27, Ioseb Dzmanashvili wrote: > > > These actions are for application users(people). > > If the end user is human ... why not use HTML? > > Jan --510c28fe_60cd4385_28a Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Jan,

> If the end u= ser is human ... why not use HTML=3F

In this par= ticular case it's an Obj-C App. It's not an HTML app.

ioseb
=20

On Saturday, =46ebruar= y 2, 2013 at 12:41 AM, Jan Algermissen wrote:


On 01.02.2013, at= 21:27, Ioseb Dzmanashvili <ioseb.dzmanashvili=40gmail.com> wrote:

<= /div>
These actions are for application= users(people).

If the end user is = human ... why not use HTML=3F

Jan
=20 =20 =20 =20
=20

--510c28fe_60cd4385_28a-- From darrel.miller@gmail.com Fri Feb 1 12:46:25 2013 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 3EB4021F904A for ; Fri, 1 Feb 2013 12:46:25 -0800 (PST) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 77K49w7JLW+w for ; Fri, 1 Feb 2013 12:46:24 -0800 (PST) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 36E6421F9049 for ; Fri, 1 Feb 2013 12:46:23 -0800 (PST) Received: by mail-la0-f54.google.com with SMTP id gw10so3091968lab.41 for ; Fri, 01 Feb 2013 12:46:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=d3VNCBJxLjwSqEa8NCQw6MZxLakNeMcEFB6Ito2609M=; b=Jwwa+H3ZCCAPXHtmIxqZY63JzxJ6Pxk1y/+itJofDgeALGQxxJtrV4n4f3tA+M0p49 hmfMBwQWNPdfLUC5RaM803++lkzK+0e4rifMzQdbcy8SHtziXmtqQO1ddwh9SAK5j2IM t6KnviH748+ifRkPXE+qyI4lPgI1MmJ0fGY++7U4XQcCxeBBPMUMcagOVh6UBC2AdnFq BZhaBddrsSP8i+gbqSdn93MmfrNFRCEFF2W41u7TxISUFl6/c1bMdMQZki9gFxgdbh/U HXIPCHAYfagDf6CLpWVxdeMLoi1BSU+BOxTk55ZsUxdpenlSVl2JMukBRTRgsly53wq9 1aQA== MIME-Version: 1.0 X-Received: by 10.152.123.194 with SMTP id mc2mr11968479lab.7.1359751582881; Fri, 01 Feb 2013 12:46:22 -0800 (PST) Received: by 10.152.109.204 with HTTP; Fri, 1 Feb 2013 12:46:22 -0800 (PST) In-Reply-To: <194C0630-AEAB-4788-A48E-CF425FC2D95F@nordsc.com> References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> <194C0630-AEAB-4788-A48E-CF425FC2D95F@nordsc.com> Date: Fri, 1 Feb 2013 15:46:22 -0500 Message-ID: Subject: Re: NEW RELATION: action From: Darrel Miller To: Jan Algermissen Content-Type: multipart/alternative; boundary=f46d04426eda1496c104d4afd603 Cc: mca , link-relations , Ioseb Dzmanashvili X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: darrel@tavis.ca List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 20:46:25 -0000 --f46d04426eda1496c104d4afd603 Content-Type: text/plain; charset=ISO-8859-1 Because HTML is designed to represent the semantic content of a textual document. The fact that it has been abused to be used for everything under the sun does not mean that there are not better media types out there for other scenarios. For example, for rendering UIs for sets of structured data, HTML is severely lacking. Darrel On Fri, Feb 1, 2013 at 3:41 PM, Jan Algermissen wrote: > > On 01.02.2013, at 21:27, Ioseb Dzmanashvili > wrote: > > > These actions are for application users(people). > > If the end user is human ... why not use HTML? > > Jan > > _______________________________________________ > link-relations mailing list > link-relations@ietf.org > https://www.ietf.org/mailman/listinfo/link-relations > --f46d04426eda1496c104d4afd603 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Because HTML is designed to represent the semantic content= of a textual document. =A0The fact that it has been abused to be used for = everything under the sun does not mean that there are not better media type= s out there for other scenarios. =A0For example, for rendering UIs for sets= of structured data, HTML is=A0severely=A0lacking.

Darrel



On Fri, Feb 1, 2013 at 3:41 PM, Ja= n Algermissen <jan.algermissen@nordsc.com> wrote:

On 01.02.2013, at 21:27, Ioseb Dzmanashvili <ioseb.dzmanashvili@gmail.com> wrote:

> These actions are for application users(people).

If the end user is human ... why not use HTML?

Jan

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

--f46d04426eda1496c104d4afd603-- From jan.algermissen@nordsc.com Fri Feb 1 13:34:58 2013 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 7F36721E8082 for ; Fri, 1 Feb 2013 13:34:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.129 X-Spam-Level: X-Spam-Status: No, score=-2.129 tagged_above=-999 required=5 tests=[AWL=0.120, 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 WxAiJ4LEz30N for ; Fri, 1 Feb 2013 13:34:57 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by ietfa.amsl.com (Postfix) with ESMTP id D55E921E804A for ; Fri, 1 Feb 2013 13:34:55 -0800 (PST) Received: from [192.168.2.103] (p548F9F56.dip.t-dialin.net [84.143.159.86]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0LosLT-1UdkCz4Bhb-00gf6m; Fri, 01 Feb 2013 22:34:55 +0100 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: NEW RELATION: action From: Jan Algermissen In-Reply-To: Date: Fri, 1 Feb 2013 22:34:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7338D97E-0362-486B-AAF1-F9CD64813213@nordsc.com> References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> <-3128426172162859719@unknownmsgid> <022b01ce0085$a4452b90$eccf82b0$@tavis.ca> <6D2125B5-02DE-4016-86BA-38F8FA100DB4@nordsc.com> <3F268583-BC18-412F-8348-16AFB070EC21@nordsc.com> <694EDD73-FAB5-419E-B72D-717F5F7F21BF@nordsc.com> To: darrel@tavis.ca X-Mailer: Apple Mail (2.1499) X-Provags-ID: V02:K0:jRRVLQ9sreOqpEOKqbgnQAPLF9foDL16AvdHRaNfYqX w6T+8k2GO/GkKDtvuPF3lfZrlibkVPPEoR1yhpTV6qjCuMcz8s QZN2kFquLqA6U+GSr8I8PLFsSAOyzs1EojnsBdPNeuMK7OrfHw AcwIqgc04JyPOfmyrmhqYf7ptH4JzB24OaJVIgHvmio/tDeQcg KW6NYILlTBu0820eXUsgENkCTRugfWJWRQwbjkUMnOIHJ0AyBp hsqeMuTn1Th1eQrvcE3amb+mCGppH2k4LXduFhwFlyLWwJR+AL SH4QpBXTQ5PFyJHQJ66/Olg2jfmBftpnEeACUUYXOvDacM8vXu +wtMvlSYzKYpPbL4js7HRi1N1n/u1p7O948BRWgXxiBM70LtW7 YiOWOr3uOLWYw== Cc: link-relations , 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: Fri, 01 Feb 2013 21:34:58 -0000 On 01.02.2013, at 21:43, Darrel Miller wrote: >=20 > So, does this example meet your constraints? >=20 >=20 > > POST /myservice > > Content-type: application/x-www-urlencoded-form > > action=3Drestart >=20 > I don't see how this is more self-descriptive. =20 It is not. The media type is too generic. I'd redesign the whole thing to (maybe) yield more overall value in = terms of re-use etc. When you restart something, you create something (a process of some = sort). I'd be interested in that process (e.g. to monitor it, share it's = link etc.) I'd also like to have an extensible format (maybe several incompatible = variants in the future, to conneg on) that I can use to specify = information about the job to start. E.g. POST /processes Content-Type: application/foo.process MyService ... IOW, the fact that a service is restarted feels like an implementation = detail, covering up what you really want to achieve and in addition = leaking out, leading to a less stable-over-time API. That's all gut feeling, but it is the same gut feeling every time I see = POST /service?myAction . Not doing this, usually triggers thoughts = leading down a path to a better (more coarse grained, reusable, = evolvable) API. > Just because I created a payload, why is that now magically kosher. >=20 > create-form and edit-form are great, but what about when I'm not = creating or editing resources? I'd say that you can almost always understand a POST to create something = (e.g. a process). Even if it is just the process of doing whatever the = POST triggers on the server. It often has an end state I'd like to be = able to review or share or use as a starting point to proceed through = the application. >=20 >=20 > =20 > So, why not use that one and render a button for it. Upon clicking the = button, the client can download the form, display an overlay to enter = the data and present a 'send' button.? >=20 >=20 > Because there is no data to send. The entire UI interaction is = _pressing_ the button. See comments above (and IMHO it smells RPCish and is ... boring ... if = the latter counts as an API design principle :-). Jan >=20 > Let me provide a visual example =20 >=20 > = http://demo.presscoders.com/designfolio/files/2012/04/launchButton-logo-bi= g.jpg >=20 > :-) >=20 > Darrel > =20 From mca@amundsen.com Fri Feb 1 13:41:36 2013 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 C730721E8083 for ; Fri, 1 Feb 2013 13:41:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.079 X-Spam-Level: X-Spam-Status: No, score=-0.079 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FORGED_YAHOO_RCVD=2.297, HTML_MESSAGE=0.001, J_CHICKENPOX_38=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 k6v4+Xz7R-MJ for ; Fri, 1 Feb 2013 13:41:35 -0800 (PST) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) by ietfa.amsl.com (Postfix) with ESMTP id 65C9221E8050 for ; Fri, 1 Feb 2013 13:41:35 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id fm10so3341681wgb.9 for ; Fri, 01 Feb 2013 13:41:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :x-gm-message-state; bh=sTyf65Myemxwc33NwBDc3swFo0jDSJ7OgEOgLzfG6v8=; b=i0MwXFbOXezwTdZqBbr5gUoJ/TIK08Nb8WrFRmMazveX1jbG8fKl+y2GsOR7i2Vz4g JLC+1C2VsUvLaNkC+GodwSPZblpXAZs2wmhvsjiuoXpW1DB/P2jhJXgCUqYL0ISRmFMN uPfYHZM0tMi2Os3Mt1yGqv2wPzInMGgqVC0Su0RXkMg/lJnhOdMa/a1Gifuqb0SGYf4Y RtG2TEaLt+4NEYyBCzybxlHkHSmPNCsZTeVx8ziQIZZjhDU7aduEGi5n2r6/Kk035F5O Z9DigvTJaZptV5Y6sA6LLmjqEAmenyZx92SDAXkMwD7XHUsB7SMpt1t1eewjRuWTjk/z I6BQ== X-Received: by 10.180.84.131 with SMTP id z3mr178609wiy.25.1359754894208; Fri, 01 Feb 2013 13:41:34 -0800 (PST) MIME-Version: 1.0 Sender: mca@amundsen.com Received: by 10.194.166.36 with HTTP; Fri, 1 Feb 2013 13:41:13 -0800 (PST) In-Reply-To: <7338D97E-0362-486B-AAF1-F9CD64813213@nordsc.com> References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> <-3128426172162859719@unknownmsgid> <022b01ce0085$a4452b90$eccf82b0$@tavis.ca> <6D2125B5-02DE-4016-86BA-38F8FA100DB4@nordsc.com> <3F268583-BC18-412F-8348-16AFB070EC21@nordsc.com> <694EDD73-FAB5-419E-B72D-717F5F7F21BF@nordsc.com> <7338D97E-0362-486B-AAF1-F9CD64813213@nordsc.com> From: mike amundsen Date: Fri, 1 Feb 2013 16:41:13 -0500 X-Google-Sender-Auth: XbaqzFRIOvi16NjVL2WExSex-YE Message-ID: Subject: Re: NEW RELATION: action To: Jan Algermissen Content-Type: multipart/alternative; boundary=f46d043bdd64736d5504d4b09ba3 X-Gm-Message-State: ALoCoQmqd0Z+Rxw+7z1FvipTJEyhyOXMGB48s8GI+mh6aASVTFUN8kQsnsVws7tSC5WFfAlKeRSy Cc: darrel@tavis.ca, Ioseb Dzmanashvili , link-relations 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, 01 Feb 2013 21:41:36 -0000 --f46d043bdd64736d5504d4b09ba3 Content-Type: text/plain; charset=ISO-8859-1 Is "action" going to be defined as MUST NOT be applied to a form-like element in the message? IOW, is action only valid when there is no body to send? mamund +1.859.757.1449 skype: mca.amundsen http://amundsen.com/blog/ http://twitter.com/mamund https://github.com/mamund http://www.linkedin.com/in/mikeamundsen On Fri, Feb 1, 2013 at 4:34 PM, Jan Algermissen wrote: > > On 01.02.2013, at 21:43, Darrel Miller wrote: > > > > > So, does this example meet your constraints? > > > > > > > POST /myservice > > > Content-type: application/x-www-urlencoded-form > > > action=restart > > > > I don't see how this is more self-descriptive. > > It is not. The media type is too generic. > > I'd redesign the whole thing to (maybe) yield more overall value in terms > of re-use etc. > > When you restart something, you create something (a process of some sort). > I'd be interested in that process (e.g. to monitor it, share it's link etc.) > > I'd also like to have an extensible format (maybe several incompatible > variants in the future, to conneg on) that I can use to specify information > about the job to start. > > E.g. > > POST /processes > Content-Type: application/foo.process > > > MyService > ... > > > IOW, the fact that a service is restarted feels like an implementation > detail, covering up what you really want to achieve and in addition leaking > out, leading to a less stable-over-time API. > > That's all gut feeling, but it is the same gut feeling every time I see > POST /service?myAction . Not doing this, usually triggers thoughts leading > down a path to a better (more coarse grained, reusable, evolvable) API. > > > > > Just because I created a payload, why is that now magically kosher. > > > > create-form and edit-form are great, but what about when I'm not > creating or editing resources? > > I'd say that you can almost always understand a POST to create something > (e.g. a process). Even if it is just the process of doing whatever the POST > triggers on the server. It often has an end state I'd like to be able to > review or share or use as a starting point to proceed through the > application. > > > > > > > > > So, why not use that one and render a button for it. Upon clicking the > button, the client can download the form, display an overlay to enter the > data and present a 'send' button.? > > > > > > Because there is no data to send. The entire UI interaction is > _pressing_ the button. > > See comments above (and IMHO it smells RPCish and is ... boring ... if the > latter counts as an API design principle :-). > > Jan > > > > > > Let me provide a visual example > > > > > http://demo.presscoders.com/designfolio/files/2012/04/launchButton-logo-big.jpg > > > > :-) > > > > Darrel > > > > _______________________________________________ > link-relations mailing list > link-relations@ietf.org > https://www.ietf.org/mailman/listinfo/link-relations > --f46d043bdd64736d5504d4b09ba3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Is "action" going to be defined as MUST NOT be applied to a form-= like element in the message? IOW, is action only valid when there is no bod= y to send?




On Fri, Feb 1, 2013 at 4:34 PM, Jan Alge= rmissen <jan.algermissen@nordsc.com> wrote:

On 01.02.2013, at 21:43, Darrel Miller <darrel.miller@gmail.com> wrote:

>
> So, does this example meet your constraints?
>
>
> > POST /myservice
> > Content-type: application/x-www-urlencoded-form
> > action=3Drestart
>
> I don't see how this is more self-descriptive.

It is not. The media type is too generic.

I'd redesign the whole thing to (maybe) yield more overall value in ter= ms of re-use etc.

When you restart something, you create something (a process of some sort). = I'd be interested in that process (e.g. to monitor it, share it's l= ink etc.)

I'd also like to have an extensible format (maybe several incompatible = variants in the future, to conneg on) that I can use to specify information= about the job to start.

E.g.

POST /processes
Content-Type: application/foo.process

<process>
=A0 <type>MyService</type>
=A0 <priority>...</priority>
</process>

IOW, the fact that a service is restarted feels like an implementation deta= il, covering up what you really want to achieve and in addition leaking out= , leading to a less stable-over-time API.

That's all gut feeling, but it is the same gut feeling every time I see= POST /service?myAction . Not doing this, usually triggers thoughts leading= down a path to a better (more coarse grained, reusable, evolvable) API.



> Just because I created a payload, why is that now magically kosher. >
> create-form and edit-form are great, but what about when I'm not c= reating or editing resources?

I'd say that you can almost always understand a POST to create so= mething (e.g. a process). Even if it is just the process of doing whatever = the POST triggers on the server. It often has an end state I'd like to = be able to review or share or use as a starting point to proceed through th= e application.

>
>
>
> So, why not use that one and render a button for it. Upon clicking the= button, the client can download the form, display an overlay to enter the = data and present a 'send' button.?
>
>
> Because there is no data to send. =A0The entire UI interaction is _pre= ssing_ the button.

See comments above (and IMHO it smells RPCish and is ... boring ... i= f the latter counts as an API design principle :-).

Jan


>
> Let me provide a visual example
>
> http://demo.presscoders.com/designf= olio/files/2012/04/launchButton-logo-big.jpg
>
> :-)
>
> Darrel
>

_____________________________= __________________
link-relations mailing list
link-relations@ietf.org
https://www.ietf.org/mailman/listinfo/link-relations

--f46d043bdd64736d5504d4b09ba3-- From ioseb.dzmanashvili@gmail.com Fri Feb 1 13:48:45 2013 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 23FC221E8041 for ; Fri, 1 Feb 2013 13:48:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=0.366, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_38=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 g2cxcEcYDzxF for ; Fri, 1 Feb 2013 13:48:44 -0800 (PST) Received: from mail-ea0-f170.google.com (mail-ea0-f170.google.com [209.85.215.170]) by ietfa.amsl.com (Postfix) with ESMTP id D3A0421F8CE2 for ; Fri, 1 Feb 2013 13:48:40 -0800 (PST) Received: by mail-ea0-f170.google.com with SMTP id a11so2000195eaa.29 for ; Fri, 01 Feb 2013 13:48:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:message-id:in-reply-to:references :subject:x-mailer:mime-version:content-type; bh=xGw/2ySBYWpA2G7+pWJKownxNpYiteolp0HnKgUJx/c=; b=vaJPbAjlCibyWYuEW30OduRany1QAsPsx9yvJVH8KEH5dbviQFeCTmPoguiNjQWj34 vbINpFbsUqrywJd57FCDa3rV88acNkG0rN6xdAV170hQtp/gIdIH+ADfcwghMHDxzTbB B6CrguoAARNgA9ndCMvhBysJV7q3a6/koj1LUPOVuvS0quojhjJjYueJL4P2qicKaNnH v8PPsBTSTVDBwwChlJxtrsuHrXftX0mLpJe7FziUwNdG7RffkDNggzTGxPTwM8kBt0bC CKUTTO3UcP5cn1nspj1Uwl6mC0aaZxYgdDCpT2QMzc/YuQnY5pVhA2E4OZ1GMyHNtQVB SZbQ== X-Received: by 10.14.221.9 with SMTP id q9mr44085605eep.3.1359755319836; Fri, 01 Feb 2013 13:48:39 -0800 (PST) Received: from [192.168.1.3] ([176.73.174.236]) by mx.google.com with ESMTPS id d3sm14510990eeo.13.2013.02.01.13.48.36 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 01 Feb 2013 13:48:38 -0800 (PST) Date: Sat, 2 Feb 2013 01:48:35 +0400 From: Ioseb Dzmanashvili To: mike amundsen Message-ID: <4522B945ABF34A74A39FCE1A0C68A9D2@gmail.com> In-Reply-To: References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> <-3128426172162859719@unknownmsgid> <022b01ce0085$a4452b90$eccf82b0$@tavis.ca> <6D2125B5-02DE-4016-86BA-38F8FA100DB4@nordsc.com> <3F268583-BC18-412F-8348-16AFB070EC21@nordsc.com> <694EDD73-FAB5-419E-B72D-717F5F7F21BF@nordsc.com> <7338D97E-0362-486B-AAF1-F9CD64813213@nordsc.com> Subject: Re: NEW RELATION: action X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="510c3833_13e08266_28a" Cc: darrel@tavis.ca, link-relations 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, 01 Feb 2013 21:48:45 -0000 --510c3833_13e08266_28a Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Mike, > Is "action" going to be defined as MUST NOT be applied to a form-like element in the message? IOW, is action only valid when there is no body to send? As of current definition: "In order to perform action, clients SHOULD send an empty POST request to the target resource." More details are in section 3.1. [1] While writing spec i didn't have such use cases(i.e. applying it to form like elements in the message) and driving use cases were as i already mentioned several times in this thread simple true/false like actions. I'd be happy to hear about more use cases though. [1]. http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-00#section-3.1 Cheers, ioseb On Saturday, February 2, 2013 at 1:41 AM, mike amundsen wrote: > Is "action" going to be defined as MUST NOT be applied to a form-like element in the message? IOW, is action only valid when there is no body to send? > > > mamund > +1.859.757.1449 > skype: mca.amundsen > http://amundsen.com/blog/ > http://twitter.com/mamund > https://github.com/mamund > http://www.linkedin.com/in/mikeamundsen > > On Fri, Feb 1, 2013 at 4:34 PM, Jan Algermissen wrote: > > > > On 01.02.2013, at 21:43, Darrel Miller wrote: > > > > > > > > So, does this example meet your constraints? > > > > > > > > > > POST /myservice > > > > Content-type: application/x-www-urlencoded-form > > > > action=restart > > > > > > I don't see how this is more self-descriptive. > > > > It is not. The media type is too generic. > > > > I'd redesign the whole thing to (maybe) yield more overall value in terms of re-use etc. > > > > When you restart something, you create something (a process of some sort). I'd be interested in that process (e.g. to monitor it, share it's link etc.) > > > > I'd also like to have an extensible format (maybe several incompatible variants in the future, to conneg on) that I can use to specify information about the job to start. > > > > E.g. > > > > POST /processes > > Content-Type: application/foo.process > > > > > > MyService > > ... > > > > > > IOW, the fact that a service is restarted feels like an implementation detail, covering up what you really want to achieve and in addition leaking out, leading to a less stable-over-time API. > > > > That's all gut feeling, but it is the same gut feeling every time I see POST /service?myAction . Not doing this, usually triggers thoughts leading down a path to a better (more coarse grained, reusable, evolvable) API. > > > > > > > > > Just because I created a payload, why is that now magically kosher. > > > > > > create-form and edit-form are great, but what about when I'm not creating or editing resources? > > > > I'd say that you can almost always understand a POST to create something (e.g. a process). Even if it is just the process of doing whatever the POST triggers on the server. It often has an end state I'd like to be able to review or share or use as a starting point to proceed through the application. > > > > > > > > > > > > > > So, why not use that one and render a button for it. Upon clicking the button, the client can download the form, display an overlay to enter the data and present a 'send' button.? > > > > > > > > > Because there is no data to send. The entire UI interaction is _pressing_ the button. > > > > See comments above (and IMHO it smells RPCish and is ... boring ... if the latter counts as an API design principle :-). > > > > Jan > > > > > > > > > > Let me provide a visual example > > > > > > http://demo.presscoders.com/designfolio/files/2012/04/launchButton-logo-big.jpg > > > > > > :-) > > > > > > Darrel > > > > > > > _______________________________________________ > > link-relations mailing list > > link-relations@ietf.org (mailto:link-relations@ietf.org) > > https://www.ietf.org/mailman/listinfo/link-relations > --510c3833_13e08266_28a Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Mike,

> Is =22action=22 = going to be defined as MUST NOT be applied to a form-like element in the = message=3F IOW, is action only valid when there is no body to send=3F

As of current definition: =22In order to perform ac= tion, clients SHOULD send an empty POST request to the target resource.=22= More details are in section 3.1. =5B1=5D

While = writing spec i didn't have such use cases(i.e. applying it to form like e= lements in the message) and driving use cases were as i already mentioned= several times in this thread simple true/false like actions. I'd be happ= y to hear about more use cases though. 


Cheers,
ioseb
=20

On Saturday, =46ebruar= y 2, 2013 at 1:41 AM, mike amundsen wrote:

Is =22action=22 going to be defined a= s MUST NOT be applied to a form-like element in the message=3F IOW, is ac= tion only valid when there is no body to send=3F




On =46ri, =46eb 1, 2013 at 4:34 PM, Jan Algermissen <jan.algermissen=40nordsc.com> wrote:

On 01.02.2013, at 21:43, Darrel Miller <darrel.miller=40gmail.com> wrote:

>
> So, does this example meet your constraints=3F
>
>
> > POST /myservice
> > Content-type: application/x-www-urlencoded-form
> > action=3Drestart
>
> I don't see how this is more self-descriptive.

It is not. The media type is too generic.

I'd redesign the whole thing to (maybe) yield more overall value in terms= of re-use etc.

When you restart something, you create something (a process of some sort)= . I'd be interested in that process (e.g. to monitor it, share it's link = etc.)

I'd also like to have an extensible format (maybe several incompatible va= riants in the future, to conneg on) that I can use to specify information= about the job to start.

E.g.

POST /processes
Content-Type: application/foo.process

<process>
  <type>MyService</type>
  <priority>...</priority>
</process>

IOW, the fact that a service is restarted feels like an implementation de= tail, covering up what you really want to achieve and in addition leaking= out, leading to a less stable-over-time API.

That's all gut feeling, but it is the same gut feeling every time I see P= OST /service=3FmyAction . Not doing this, usually triggers thoughts leadi= ng down a path to a better (more coarse grained, reusable, evolvable) API= .



> Just because I created a payload, why is that now magically kosher.<= br> >
> create-form and edit-form are great, but what about when I'm not cre= ating or editing resources=3F

I'd say that you can almost always understand a POST to create some= thing (e.g. a process). Even if it is just the process of doing whatever = the POST triggers on the server. It often has an end state I'd like to be= able to review or share or use as a starting point to proceed through th= e application.

>
>
>
> So, why not use that one and render a button for it. Upon clicking t= he button, the client can download the form, display an overlay to enter = the data and present a 'send' button.=3F
>
>
> Because there is no data to send.  The entire UI interaction is= =5Fpressing=5F the button.

See comments above (and IMHO it smells RPCish and is ... boring ...= if the latter counts as an API design principle :-).

Jan


>
> Let me provide a visual example
>
> http://demo.presscode= rs.com/designfolio/files/2012/04/launchButton-logo-big.jpg
>
> :-)
>
> Darrel
>

=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 mailing list
link-relations=40ietf.or= g
https://www.ietf.org/mailman/listinfo/link-relations<= /a>

 =20 =20 =20 =20
=20

--510c3833_13e08266_28a-- From darrel.miller@gmail.com Fri Feb 1 13:50:56 2013 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 D999721E8049 for ; Fri, 1 Feb 2013 13:50:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, NO_RELAYS=-0.001] 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 itTVui4UNsnu for ; Fri, 1 Feb 2013 13:50:54 -0800 (PST) Received: from mail-la0-x234.google.com (la-in-x0234.1e100.net [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 8E80121E8041 for ; Fri, 1 Feb 2013 13:50:53 -0800 (PST) Received: by mail-la0-f52.google.com with SMTP id fs12so3214670lab.11 for ; Fri, 01 Feb 2013 13:50:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=2V84tf1sblFaifikpikzWC6xyIULjaBJ4ioq6f4gUQg=; b=pAaeHCW2ELXlPh0y3XZoCrRlbNgIM6wKtjcaJRk9gJ4Alx3yiT+McjLE3sSIIcet9q 4FQkKGIcN6Amh2S1BhAou2vssARoYwtaGEuuAy+DCV0ZIFv7Ln0VNUdtJSfQNdXP7rOM 9GmSrNQWngZzX4+Cf3Jol3aCpf1Kr0q87FH2p6UO8HZnluTOlZN386GmEtrs2gP+5OJV yM8PbGWerNKx3iqdcS2vwLci7Q1rfsrIp4KlgocYfpf0hU4SHuz1EXwIQuLzGmt/av1s 4scWwUyVetsKzae2V5Zr0kJ92Ynj+EzWtgV9ig4rrFSJebw5CLL0MOoO5q6Z8Ji6lPFV PTZg== MIME-Version: 1.0 X-Received: by 10.152.121.212 with SMTP id lm20mr12375326lab.42.1359755452438; Fri, 01 Feb 2013 13:50:52 -0800 (PST) Received: by 10.152.109.204 with HTTP; Fri, 1 Feb 2013 13:50:52 -0800 (PST) In-Reply-To: References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> <-3128426172162859719@unknownmsgid> <022b01ce0085$a4452b90$eccf82b0$@tavis.ca> <6D2125B5-02DE-4016-86BA-38F8FA100DB4@nordsc.com> <3F268583-BC18-412F-8348-16AFB070EC21@nordsc.com> <694EDD73-FAB5-419E-B72D-717F5F7F21BF@nordsc.com> <7338D97E-0362-486B-AAF1-F9CD64813213@nordsc.com> Date: Fri, 1 Feb 2013 16:50:52 -0500 Message-ID: Subject: Re: NEW RELATION: action From: Darrel Miller To: mike amundsen Content-Type: multipart/alternative; boundary=f46d04374ee1b95a5204d4b0bc98 Cc: link-relations , Ioseb Dzmanashvili X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: darrel@tavis.ca List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 21:50:56 -0000 --f46d04374ee1b95a5204d4b0bc98 Content-Type: text/plain; charset=ISO-8859-1 Mike, Speaking for myself only, I would see value to limiting "action" to be only for POST with no body. If you do not apply this constraint, then how can a client know what type of body should be posted. I know Ioseb was suggesting that a second "extended type" rel could be used to provide additional details however, there is a phrase in RFC 5988... "Relation types SHOULD NOT infer any additional semantics based upon the presence or absence of another link relation type, or its own cardinality of occurrence" Which I interpret as meaning, that "action" and the extended type must stand alone independently and different clients just interpret one or the other. Therefore, for me, there is no way for an "action" link relation to assist a client in formulating a body. Darrel On Fri, Feb 1, 2013 at 4:41 PM, mike amundsen wrote: > Is "action" going to be defined as MUST NOT be applied to a form-like > element in the message? IOW, is action only valid when there is no body to > send? > > > mamund > +1.859.757.1449 > skype: mca.amundsen > http://amundsen.com/blog/ > http://twitter.com/mamund > https://github.com/mamund > http://www.linkedin.com/in/mikeamundsen > > > On Fri, Feb 1, 2013 at 4:34 PM, Jan Algermissen < > jan.algermissen@nordsc.com> wrote: > >> >> On 01.02.2013, at 21:43, Darrel Miller wrote: >> >> > >> > So, does this example meet your constraints? >> > >> > >> > > POST /myservice >> > > Content-type: application/x-www-urlencoded-form >> > > action=restart >> > >> > I don't see how this is more self-descriptive. >> >> It is not. The media type is too generic. >> >> I'd redesign the whole thing to (maybe) yield more overall value in terms >> of re-use etc. >> >> When you restart something, you create something (a process of some >> sort). I'd be interested in that process (e.g. to monitor it, share it's >> link etc.) >> >> I'd also like to have an extensible format (maybe several incompatible >> variants in the future, to conneg on) that I can use to specify information >> about the job to start. >> >> E.g. >> >> POST /processes >> Content-Type: application/foo.process >> >> >> MyService >> ... >> >> >> IOW, the fact that a service is restarted feels like an implementation >> detail, covering up what you really want to achieve and in addition leaking >> out, leading to a less stable-over-time API. >> >> That's all gut feeling, but it is the same gut feeling every time I see >> POST /service?myAction . Not doing this, usually triggers thoughts leading >> down a path to a better (more coarse grained, reusable, evolvable) API. >> >> >> >> > Just because I created a payload, why is that now magically kosher. >> > >> > create-form and edit-form are great, but what about when I'm not >> creating or editing resources? >> >> I'd say that you can almost always understand a POST to create something >> (e.g. a process). Even if it is just the process of doing whatever the POST >> triggers on the server. It often has an end state I'd like to be able to >> review or share or use as a starting point to proceed through the >> application. >> >> > >> > >> > >> > So, why not use that one and render a button for it. Upon clicking the >> button, the client can download the form, display an overlay to enter the >> data and present a 'send' button.? >> > >> > >> > Because there is no data to send. The entire UI interaction is >> _pressing_ the button. >> >> See comments above (and IMHO it smells RPCish and is ... boring ... if >> the latter counts as an API design principle :-). >> >> Jan >> >> >> > >> > Let me provide a visual example >> > >> > >> http://demo.presscoders.com/designfolio/files/2012/04/launchButton-logo-big.jpg >> > >> > :-) >> > >> > Darrel >> > >> >> _______________________________________________ >> link-relations mailing list >> link-relations@ietf.org >> https://www.ietf.org/mailman/listinfo/link-relations >> > > > _______________________________________________ > link-relations mailing list > link-relations@ietf.org > https://www.ietf.org/mailman/listinfo/link-relations > > --f46d04374ee1b95a5204d4b0bc98 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Mike,

Speaking for myself only, I= would see value to limiting "action" to be only for POST with no= body. If you do not apply this constraint, then how can a client know what= type of body should be posted.

I know Ioseb was suggesting that a second &= quot;extended type" rel could be used to provide additional details ho= wever, there is a phrase in RFC 5988...

"Relation types SHOULD NOT infer any additiona= l semantics based upon
=A0 =A0the = presence or absence of another link relation type, or its own
<= div style> =A0 =A0cardinality of occurrence"
=

Which I interpret as meaning, that "ac= tion" and the extended type must stand alone independently and differe= nt clients just interpret one or the other. =A0Therefore, for me, there is = no way for an "action" link relation to assist a client in formul= ating a body.


Darrel
=A0


On Fri, Feb 1, 2013 at 4:41 PM, mike amundsen <mamund@yahoo.com><= /span> wrote:
Is "action" going to be defined as= MUST NOT be applied to a form-like element in the message? IOW, is action = only valid when there is no body to send?




On Fri, Feb 1, 2013 at 4:34 PM, Jan Alge= rmissen <jan.algermissen@nordsc.com> wrote:

On 01.02.2013, at 21:43, Darrel Miller <darrel.miller@gmail.com> wrote:

>
> So, does this example meet your constraints?
>
>
> > POST /myservice
> > Content-type: application/x-www-urlencoded-form
> > action=3Drestart
>
> I don't see how this is more self-descriptive.

It is not. The media type is too generic.

I'd redesign the whole thing to (maybe) yield more overall value in ter= ms of re-use etc.

When you restart something, you create something (a process of some sort). = I'd be interested in that process (e.g. to monitor it, share it's l= ink etc.)

I'd also like to have an extensible format (maybe several incompatible = variants in the future, to conneg on) that I can use to specify information= about the job to start.

E.g.

POST /processes
Content-Type: application/foo.process

<process>
=A0 <type>MyService</type>
=A0 <priority>...</priority>
</process>

IOW, the fact that a service is restarted feels like an implementation deta= il, covering up what you really want to achieve and in addition leaking out= , leading to a less stable-over-time API.

That's all gut feeling, but it is the same gut feeling every time I see= POST /service?myAction . Not doing this, usually triggers thoughts leading= down a path to a better (more coarse grained, reusable, evolvable) API.



> Just because I created a payload, why is that now magically kosher. >
> create-form and edit-form are great, but what about when I'm not c= reating or editing resources?

I'd say that you can almost always understand a POST to create so= mething (e.g. a process). Even if it is just the process of doing whatever = the POST triggers on the server. It often has an end state I'd like to = be able to review or share or use as a starting point to proceed through th= e application.

>
>
>
> So, why not use that one and render a button for it. Upon clicking the= button, the client can download the form, display an overlay to enter the = data and present a 'send' button.?
>
>
> Because there is no data to send. =A0The entire UI interaction is _pre= ssing_ the button.

See comments above (and IMHO it smells RPCish and is ... boring ... i= f the latter counts as an API design principle :-).

Jan


>
> Let me provide a visual example
>
> http://demo.presscoders.com/designf= olio/files/2012/04/launchButton-logo-big.jpg
>
> :-)
>
> Darrel
>

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


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


--f46d04374ee1b95a5204d4b0bc98-- From mca@amundsen.com Fri Feb 1 13:52:24 2013 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 967C321F88FB for ; Fri, 1 Feb 2013 13:52:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.521 X-Spam-Level: X-Spam-Status: No, score=0.521 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FORGED_YAHOO_RCVD=2.297, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=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 1xCEFGUkYG7S for ; Fri, 1 Feb 2013 13:52:20 -0800 (PST) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC9721F86F5 for ; Fri, 1 Feb 2013 13:52:12 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id dr12so3266823wgb.35 for ; Fri, 01 Feb 2013 13:52:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :x-gm-message-state; bh=fzebRNPMCjz6mgsYbQMQ08JfLjcI6e1+scKeZKSPK5A=; b=hOHmJGMbxV/+PD8sFHKvRi/XvD8UzwJ3joVMPUFO1yEmnoW9jJUbxChE2QRDb5Va7q +7VGn3ERgpM1S/onhK/+OPRj4aKjS9BH/N6Pmo5VivNnzCzAc+J7hHENr58mJjUoEZf4 dTk6aupcSbxkSSxPUyFugHn/S/X6ddYCdComH0bLtI4757I8R5r8Z3Cz7J/2b5srPU5D sFHUkEUZbkvn7Z+/HjCVLNBu//vMArECmtAQ1Z4UQ4ygHn4bZoeqTqMni948+xGyNsRP 7TcViuKG05/9XYb32hu4XPNuYYkQHFX57SpuoUQ1RN2uj3oVkkpG2/c8IbYtv4wAoC+l QXtg== X-Received: by 10.180.82.41 with SMTP id f9mr208266wiy.25.1359755531530; Fri, 01 Feb 2013 13:52:11 -0800 (PST) MIME-Version: 1.0 Sender: mca@amundsen.com Received: by 10.194.166.36 with HTTP; Fri, 1 Feb 2013 13:51:51 -0800 (PST) In-Reply-To: <4522B945ABF34A74A39FCE1A0C68A9D2@gmail.com> References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> <-3128426172162859719@unknownmsgid> <022b01ce0085$a4452b90$eccf82b0$@tavis.ca> <6D2125B5-02DE-4016-86BA-38F8FA100DB4@nordsc.com> <3F268583-BC18-412F-8348-16AFB070EC21@nordsc.com> <694EDD73-FAB5-419E-B72D-717F5F7F21BF@nordsc.com> <7338D97E-0362-486B-AAF1-F9CD64813213@nordsc.com> <4522B945ABF34A74A39FCE1A0C68A9D2@gmail.com> From: mike amundsen Date: Fri, 1 Feb 2013 16:51:51 -0500 X-Google-Sender-Auth: L7OoasCwfs-IcL4QCCpKbDXw-ME Message-ID: Subject: Re: NEW RELATION: action To: Ioseb Dzmanashvili Content-Type: multipart/alternative; boundary=f46d041826e67030b504d4b0c166 X-Gm-Message-State: ALoCoQnCLUgmDGO66bMHVI2gJOzEXMpFuUmYSGBQuuF6TAs5ChRQ+HDRSWtjQzmq8wHS7tt2n5iA Cc: darrel@tavis.ca, link-relations 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, 01 Feb 2013 21:52:26 -0000 --f46d041826e67030b504d4b0c166 Content-Type: text/plain; charset=ISO-8859-1 so, "action" is only for sending an empty HTTP.POST request; nothing else. no other protocol use (XMPP, WS, FTP, etc.) no HTTP.PUT, PATCH, DELETE, or any other method that might be added to HTTP in the future, correct? mamund +1.859.757.1449 skype: mca.amundsen http://amundsen.com/blog/ http://twitter.com/mamund https://github.com/mamund http://www.linkedin.com/in/mikeamundsen On Fri, Feb 1, 2013 at 4:48 PM, Ioseb Dzmanashvili < ioseb.dzmanashvili@gmail.com> wrote: > Mike, > > > Is "action" going to be defined as MUST NOT be applied to a form-like > element in the message? IOW, is action only valid when there is no body to > send? > > As of current definition: "In order to perform action, clients SHOULD send > an empty POST request to the target resource." More details are in section > 3.1. [1] > > While writing spec i didn't have such use cases(i.e. applying it to form > like elements in the message) and driving use cases were as i already > mentioned several times in this thread simple true/false like actions. I'd > be happy to hear about more use cases though. > > [1]. > http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-00#section-3.1 > > Cheers, > ioseb > > On Saturday, February 2, 2013 at 1:41 AM, mike amundsen wrote: > > Is "action" going to be defined as MUST NOT be applied to a form-like > element in the message? IOW, is action only valid when there is no body to > send? > > > mamund > +1.859.757.1449 > skype: mca.amundsen > http://amundsen.com/blog/ > http://twitter.com/mamund > https://github.com/mamund > http://www.linkedin.com/in/mikeamundsen > > > On Fri, Feb 1, 2013 at 4:34 PM, Jan Algermissen < > jan.algermissen@nordsc.com> wrote: > > > On 01.02.2013, at 21:43, Darrel Miller wrote: > > > > > So, does this example meet your constraints? > > > > > > > POST /myservice > > > Content-type: application/x-www-urlencoded-form > > > action=restart > > > > I don't see how this is more self-descriptive. > > It is not. The media type is too generic. > > I'd redesign the whole thing to (maybe) yield more overall value in terms > of re-use etc. > > When you restart something, you create something (a process of some sort). > I'd be interested in that process (e.g. to monitor it, share it's link etc.) > > I'd also like to have an extensible format (maybe several incompatible > variants in the future, to conneg on) that I can use to specify information > about the job to start. > > E.g. > > POST /processes > Content-Type: application/foo.process > > > MyService > ... > > > IOW, the fact that a service is restarted feels like an implementation > detail, covering up what you really want to achieve and in addition leaking > out, leading to a less stable-over-time API. > > That's all gut feeling, but it is the same gut feeling every time I see > POST /service?myAction . Not doing this, usually triggers thoughts leading > down a path to a better (more coarse grained, reusable, evolvable) API. > > > > > Just because I created a payload, why is that now magically kosher. > > > > create-form and edit-form are great, but what about when I'm not > creating or editing resources? > > I'd say that you can almost always understand a POST to create something > (e.g. a process). Even if it is just the process of doing whatever the POST > triggers on the server. It often has an end state I'd like to be able to > review or share or use as a starting point to proceed through the > application. > > > > > > > > > So, why not use that one and render a button for it. Upon clicking the > button, the client can download the form, display an overlay to enter the > data and present a 'send' button.? > > > > > > Because there is no data to send. The entire UI interaction is > _pressing_ the button. > > See comments above (and IMHO it smells RPCish and is ... boring ... if the > latter counts as an API design principle :-). > > Jan > > > > > > Let me provide a visual example > > > > > http://demo.presscoders.com/designfolio/files/2012/04/launchButton-logo-big.jpg > > > > :-) > > > > Darrel > > > > _______________________________________________ > link-relations mailing list > link-relations@ietf.org > https://www.ietf.org/mailman/listinfo/link-relations > > > > --f46d041826e67030b504d4b0c166 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable so, "action" is only for sending an empty HTTP.POST request; noth= ing else. no other protocol use (XMPP, WS, FTP, etc.) no HTTP.PUT, PATCH, D= ELETE, or any other method that might be added to HTTP in the future, corre= ct?



On Fri, Feb 1, 2013 at 4:48 PM, Ioseb Dz= manashvili <ioseb.dzmanashvili@gmail.com> wrote:<= br>
Mike,

> = Is "action" going to be defined as MUST NOT be applied to a form-= like element in the message? IOW, is action only valid when there is no bod= y to send?

As of current definition: "In order to perfo= rm action, clients SHOULD send an empty POST request to the target resource= ." More details are in section 3.1. [1]

While writing spec i didn't have such use cases(i.e. applying it to for= m like elements in the message) and driving use cases were as i already men= tioned several times in this thread simple true/false like actions. I'd= be happy to hear about more use cases though.=A0


Cheers,
ioseb
=20

On Saturday, February 2, 2013 at= 1:41 AM, mike amundsen wrote:

Is "action" going to be defin= ed as MUST NOT be applied to a form-like element in the message? IOW, is ac= tion only valid when there is no body to send?




On Fri, Feb 1, 2013 at 4:34 PM, Jan Algermissen <jan= .algermissen@nordsc.com> wrote:
=

On 01.02.2013, at 21:43, Darrel Miller <darrel.miller@gmail.com> wrote:

>
> So, does this example meet your constraints?
>
>
> > POST /myservice
> > Content-type: application/x-www-urlencoded-form
> > action=3Drestart
>
> I don't see how this is more self-descriptive.

It is not. The media type is too generic.

I'd redesign the whole thing to (maybe) yield more overall value in ter= ms of re-use etc.

When you restart something, you create something (a process of some sort). = I'd be interested in that process (e.g. to monitor it, share it's l= ink etc.)

I'd also like to have an extensible format (maybe several incompatible = variants in the future, to conneg on) that I can use to specify information= about the job to start.

E.g.

POST /processes
Content-Type: application/foo.process

<process>
=A0 <type>MyService</type>
=A0 <priority>...</priority>
</process>

IOW, the fact that a service is restarted feels like an implementation deta= il, covering up what you really want to achieve and in addition leaking out= , leading to a less stable-over-time API.

That's all gut feeling, but it is the same gut feeling every time I see= POST /service?myAction . Not doing this, usually triggers thoughts leading= down a path to a better (more coarse grained, reusable, evolvable) API.



> Just because I created a payload, why is that now magically kosher. >
> create-form and edit-form are great, but what about when I'm not c= reating or editing resources?

I'd say that you can almost always understand a POST to create so= mething (e.g. a process). Even if it is just the process of doing whatever = the POST triggers on the server. It often has an end state I'd like to = be able to review or share or use as a starting point to proceed through th= e application.

>
>
>
> So, why not use that one and render a button for it. Upon clicking the= button, the client can download the form, display an overlay to enter the = data and present a 'send' button.?
>
>
> Because there is no data to send. =A0The entire UI interaction is _pre= ssing_ the button.

See comments above (and IMHO it smells RPCish and is ... boring ... i= f the latter counts as an API design principle :-).

Jan


>
> Let me provide a visual example
>
> http://demo.presscoders.com/designf= olio/files/2012/04/launchButton-logo-big.jpg
>
> :-)
>
> Darrel
>

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

 =20 =20 =20 =20
=20


--f46d041826e67030b504d4b0c166-- From ioseb.dzmanashvili@gmail.com Fri Feb 1 13:58:31 2013 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 33A9621E8050 for ; Fri, 1 Feb 2013 13:58:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.784 X-Spam-Level: X-Spam-Status: No, score=-1.784 tagged_above=-999 required=5 tests=[AWL=-0.586, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_46=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 SvXYkXMY4szP for ; Fri, 1 Feb 2013 13:58:29 -0800 (PST) Received: from mail-ee0-f53.google.com (mail-ee0-f53.google.com [74.125.83.53]) by ietfa.amsl.com (Postfix) with ESMTP id 3274221E8041 for ; Fri, 1 Feb 2013 13:58:29 -0800 (PST) Received: by mail-ee0-f53.google.com with SMTP id e53so2255112eek.26 for ; Fri, 01 Feb 2013 13:58:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:message-id:in-reply-to:references :subject:x-mailer:mime-version:content-type; bh=kU6S/r7m/Q9kxWrCMth0W+hAs2nUglb0TRV04f6e2Yc=; b=BB75c6KKNYZ1tckZ09iVQkfPpBiMEbnz/pqNhYKlrPrWNJeVAfncdYPeAo9w7E071C 4sJitiC5sqkdpC9MsN51Q8Hj8M+7/Bi0JGZSLUJejX6GEfqJD5WiQid1axx4lbLK4fTt 3Tl/qFdWihQ1OMe5wh9hZg0Qkly4dessRHO5ptL0WPHYUusXLFzPnBGP84pVstWFAcCB v2V1cRlTbfZ2Iq4DsWfLMdsGTF+InJzPWX1aXUO3VMBGzAS1BHnp4l63Jkz0MupZI0uZ Efq231ZjB+ym+JDwEHBiJ2oOM8VztHq33DXJ55zKxPjmDZsu5cUPADqciZYug08osNeA g4Fg== X-Received: by 10.14.193.131 with SMTP id k3mr44068116een.45.1359755908180; Fri, 01 Feb 2013 13:58:28 -0800 (PST) Received: from [192.168.1.3] ([176.73.174.236]) by mx.google.com with ESMTPS id q5sm14541424eeo.17.2013.02.01.13.58.26 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 01 Feb 2013 13:58:27 -0800 (PST) Date: Sat, 2 Feb 2013 01:58:24 +0400 From: Ioseb Dzmanashvili To: mike amundsen Message-ID: In-Reply-To: References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> <-3128426172162859719@unknownmsgid> <022b01ce0085$a4452b90$eccf82b0$@tavis.ca> <6D2125B5-02DE-4016-86BA-38F8FA100DB4@nordsc.com> <3F268583-BC18-412F-8348-16AFB070EC21@nordsc.com> <694EDD73-FAB5-419E-B72D-717F5F7F21BF@nordsc.com> <7338D97E-0362-486B-AAF1-F9CD64813213@nordsc.com> <4522B945ABF34A74A39FCE1A0C68A9D2@gmail.com> Subject: Re: NEW RELATION: action X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="510c3a80_2f298a4a_28a" Cc: darrel@tavis.ca, link-relations 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, 01 Feb 2013 21:58:31 -0000 --510c3a80_2f298a4a_28a Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Mike, > so, "action" is only for sending an empty HTTP.POST request; nothing else. no other protocol use (XMPP, WS, FTP, etc.) no HTTP.PUT, PATCH, DELETE, or any > other method that might be added to HTTP in the future, correct? Exactly, i never thought about this link relation in terms of other method than POST(except GET which is not clarified in the spec yet). Same is true regarding protocols, i never thought about using this relation with XMPP or WS etc... @Darrel > I know Ioseb was suggesting that a second "extended type" rel could be used to provide additional details however, there is a > phrase in RFC 5988... > > "Relation types SHOULD NOT infer any additional semantics based upon the presence or absence of another link relation type, > or its own cardinality of occurrence" That is why i described this possibility with MAY. ioseb On Saturday, February 2, 2013 at 1:51 AM, mike amundsen wrote: > so, "action" is only for sending an empty HTTP.POST request; nothing else. no other protocol use (XMPP, WS, FTP, etc.) no HTTP.PUT, PATCH, DELETE, or any other method that might be added to HTTP in the future, correct? > > mamund > +1.859.757.1449 > skype: mca.amundsen > http://amundsen.com/blog/ > http://twitter.com/mamund > https://github.com/mamund > http://www.linkedin.com/in/mikeamundsen > > On Fri, Feb 1, 2013 at 4:48 PM, Ioseb Dzmanashvili wrote: > > Mike, > > > > > Is "action" going to be defined as MUST NOT be applied to a form-like element in the message? IOW, is action only valid when there is no body to send? > > > > As of current definition: "In order to perform action, clients SHOULD send an empty POST request to the target resource." More details are in section 3.1. [1] > > > > While writing spec i didn't have such use cases(i.e. applying it to form like elements in the message) and driving use cases were as i already mentioned several times in this thread simple true/false like actions. I'd be happy to hear about more use cases though. > > > > [1]. http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-00#section-3.1 > > > > Cheers, > > ioseb > > > > On Saturday, February 2, 2013 at 1:41 AM, mike amundsen wrote: > > > > > Is "action" going to be defined as MUST NOT be applied to a form-like element in the message? IOW, is action only valid when there is no body to send? > > > > > > > > > mamund > > > +1.859.757.1449 (tel:%2B1.859.757.1449) > > > skype: mca.amundsen > > > http://amundsen.com/blog/ > > > http://twitter.com/mamund > > > https://github.com/mamund > > > http://www.linkedin.com/in/mikeamundsen > > > > > > On Fri, Feb 1, 2013 at 4:34 PM, Jan Algermissen wrote: > > > > > > > > On 01.02.2013, at 21:43, Darrel Miller wrote: > > > > > > > > > > > > > > So, does this example meet your constraints? > > > > > > > > > > > > > > > > POST /myservice > > > > > > Content-type: application/x-www-urlencoded-form > > > > > > action=restart > > > > > > > > > > I don't see how this is more self-descriptive. > > > > > > > > It is not. The media type is too generic. > > > > > > > > I'd redesign the whole thing to (maybe) yield more overall value in terms of re-use etc. > > > > > > > > When you restart something, you create something (a process of some sort). I'd be interested in that process (e.g. to monitor it, share it's link etc.) > > > > > > > > I'd also like to have an extensible format (maybe several incompatible variants in the future, to conneg on) that I can use to specify information about the job to start. > > > > > > > > E.g. > > > > > > > > POST /processes > > > > Content-Type: application/foo.process > > > > > > > > > > > > MyService > > > > ... > > > > > > > > > > > > IOW, the fact that a service is restarted feels like an implementation detail, covering up what you really want to achieve and in addition leaking out, leading to a less stable-over-time API. > > > > > > > > That's all gut feeling, but it is the same gut feeling every time I see POST /service?myAction . Not doing this, usually triggers thoughts leading down a path to a better (more coarse grained, reusable, evolvable) API. > > > > > > > > > > > > > > > > > Just because I created a payload, why is that now magically kosher. > > > > > > > > > > create-form and edit-form are great, but what about when I'm not creating or editing resources? > > > > > > > > I'd say that you can almost always understand a POST to create something (e.g. a process). Even if it is just the process of doing whatever the POST triggers on the server. It often has an end state I'd like to be able to review or share or use as a starting point to proceed through the application. > > > > > > > > > > > > > > > > > > > > > > > > So, why not use that one and render a button for it. Upon clicking the button, the client can download the form, display an overlay to enter the data and present a 'send' button.? > > > > > > > > > > > > > > > Because there is no data to send. The entire UI interaction is _pressing_ the button. > > > > > > > > See comments above (and IMHO it smells RPCish and is ... boring ... if the latter counts as an API design principle :-). > > > > > > > > Jan > > > > > > > > > > > > > > > > > > Let me provide a visual example > > > > > > > > > > http://demo.presscoders.com/designfolio/files/2012/04/launchButton-logo-big.jpg > > > > > > > > > > :-) > > > > > > > > > > Darrel > > > > > > > > > > > > > _______________________________________________ > > > > link-relations mailing list > > > > link-relations@ietf.org (mailto:link-relations@ietf.org) > > > > https://www.ietf.org/mailman/listinfo/link-relations > > > > > > --510c3a80_2f298a4a_28a Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Mike,

> so, =22action=22= is only for sending an empty HTTP.POST request; nothing else. no other p= rotocol use (XMPP, WS, =46TP, etc.) no HTTP.PUT, PATCH, DELETE, or any&nb= sp;
> other method that might be added to HTTP in the f= uture, correct=3F

Exactly, i never thought about= this link relation in terms of other method than POST(except GET which i= s not clarified in the spec yet). Same is true regarding protocols, i nev= er thought about using this relation with XMPP or WS etc... 

=40Darrel
> I know Ioseb was suggesti= ng that a second =22extended type=22 rel could be used to provide additio= nal details however, there is a > phrase in R=46C 5988...
&g= t; 
> =22Relation types SHOULD NOT infer any additional= semantics based upon the presence or absence of another link relation ty= pe, 
> or its own cardinality of occurrence=22

That is why i described this possibility with MAY.=

ioseb
=20

On Saturday, =46ebruar= y 2, 2013 at 1:51 AM, mike amundsen wrote:

so, =22action=22 is only for sending = an empty HTTP.POST request; nothing else. no other protocol use (XMPP, WS= , =46TP, etc.) no HTTP.PUT, PATCH, DELETE, or any other method that might= be added to HTTP in the future, correct=3F



On =46ri, =46eb 1, 2013 at 4:48 PM, Ioseb Dzmanashvili <ioseb.dzmanashvili=40gmail.com> wr= ote:
Mike,

> Is =22actio= n=22 going to be defined as MUST NOT be applied to a form-like element in= the message=3F IOW, is action only valid when there is no body to send=3F=

As of current definition: =22In order to perfor= m action, clients SHOULD send an empty POST request to the target resourc= e.=22 More details are in section 3.1. =5B1=5D

While writing spec i didn't have such use cases(i.e. applying it to form = like elements in the message) and driving use cases were as i already men= tioned several times in this thread simple true/false like actions. I'd b= e happy to hear about more use cases though. 


Cheers,
ioseb
=20

On Saturday, =46ebruary = 2, 2013 at 1:41 AM, mike amundsen wrote:

Is =22action=22 going to be defined a= s MUST NOT be applied to a form-like element in the message=3F IOW, is ac= tion only valid when there is no body to send=3F




On =46ri, =46eb 1, 2013 at 4:34 PM, Jan Algermissen <jan.algermissen=40nordsc.com> wrote:

On 01.02.2013, at 21:43, Darrel Miller <darrel.miller=40gmail.com&= gt; wrote:

>
> So, does this example meet your constraints=3F
>
>
> > POST /myservice
> > Content-type: application/x-www-urlencoded-form
> > action=3Drestart
>
> I don't see how this is more self-descriptive.

It is not. The media type is too generic.

I'd redesign the whole thing to (maybe) yield more overall value in terms= of re-use etc.

When you restart something, you create something (a process of some sort)= . I'd be interested in that process (e.g. to monitor it, share it's link = etc.)

I'd also like to have an extensible format (maybe several incompatible va= riants in the future, to conneg on) that I can use to specify information= about the job to start.

E.g.

POST /processes
Content-Type: application/foo.process

<process>
  <type>MyService</type>
  <priority>...</priority>
</process>

IOW, the fact that a service is restarted feels like an implementation de= tail, covering up what you really want to achieve and in addition leaking= out, leading to a less stable-over-time API.

That's all gut feeling, but it is the same gut feeling every time I see P= OST /service=3FmyAction . Not doing this, usually triggers thoughts leadi= ng down a path to a better (more coarse grained, reusable, evolvable) API= .



> Just because I created a payload, why is that now magically kosher.<= br> >
> create-form and edit-form are great, but what about when I'm not cre= ating or editing resources=3F

I'd say that you can almost always understand a POST to create some= thing (e.g. a process). Even if it is just the process of doing whatever = the POST triggers on the server. It often has an end state I'd like to be= able to review or share or use as a starting point to proceed through th= e application.

>
>
>
> So, why not use that one and render a button for it. Upon clicking t= he button, the client can download the form, display an overlay to enter = the data and present a 'send' button.=3F
>
>
> Because there is no data to send.  The entire UI interaction is= =5Fpressing=5F the button.

See comments above (and IMHO it smells RPCish and is ... boring ...= if the latter counts as an API design principle :-).

Jan


>
> Let me provide a visual example
>
> http://demo.presscode= rs.com/designfolio/files/2012/04/launchButton-logo-big.jpg
>
> :-)
>
> Darrel
>

=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 mailing list
= link-relations=40ietf.org
https://www.ietf.org/mailman/listinfo/link-relations<= /a>

 =20 =20 =20 =20

=20 =20 =20 =20
=20

--510c3a80_2f298a4a_28a-- From darrel.miller@gmail.com Fri Feb 1 14:05:37 2013 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 9EDD621F8DF2 for ; Fri, 1 Feb 2013 14:05:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.924 X-Spam-Level: X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[AWL=-0.525, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, NO_RELAYS=-0.001] 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 LLS4xnYdL-zn for ; Fri, 1 Feb 2013 14:05:37 -0800 (PST) Received: from mail-la0-x229.google.com (la-in-x0229.1e100.net [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id AC6DB21F844E for ; Fri, 1 Feb 2013 14:05:36 -0800 (PST) Received: by mail-la0-f41.google.com with SMTP id fo12so3219901lab.28 for ; Fri, 01 Feb 2013 14:05:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=LeXiEZN4/yblRQczl2QCLj62AEm652vCZOvYdMhPbDw=; b=MNEdL+2Fes6e/UisUj7g8bIfccsNZiZxF+fPvQSTo/5SY4OfFC59iMrL62O9U9011m LO97LSSleDn6gImESxpwOKeVSDEFHs0OdwsTckEBX8T/WgSyRYArv7B8HtAiJrxGhta5 HecUzfYNqnauJgW3j6B6ogZ4WNrcgJlvojhCCJBT9alFPufCQ4G5QbA7XRFgS9ScQzsl dOGs1tCPggeZR5SFPIE531N22NqyMPOU0BAQqEVNg6baxbM3Vcsvs8VX+csNOFFMTIRj gSeHyjKqbt6k9VvLBwQp5dCeQ1mPxFw2w1AzTOKmdNVBCnx23CWjoZIiQuawfNpYGYSK YSdQ== MIME-Version: 1.0 X-Received: by 10.112.40.129 with SMTP id x1mr5363553lbk.95.1359756333578; Fri, 01 Feb 2013 14:05:33 -0800 (PST) Received: by 10.152.109.204 with HTTP; Fri, 1 Feb 2013 14:05:33 -0800 (PST) In-Reply-To: References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> <-3128426172162859719@unknownmsgid> <022b01ce0085$a4452b90$eccf82b0$@tavis.ca> <6D2125B5-02DE-4016-86BA-38F8FA100DB4@nordsc.com> <3F268583-BC18-412F-8348-16AFB070EC21@nordsc.com> <694EDD73-FAB5-419E-B72D-717F5F7F21BF@nordsc.com> <7338D97E-0362-486B-AAF1-F9CD64813213@nordsc.com> <4522B945ABF34A74A39FCE1A0C68A9D2@gmail.com> Date: Fri, 1 Feb 2013 17:05:33 -0500 Message-ID: Subject: Re: NEW RELATION: action From: Darrel Miller To: mike amundsen Content-Type: multipart/alternative; boundary=e0cb4efe323e3e79d304d4b0f113 Cc: link-relations , Ioseb Dzmanashvili X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: darrel@tavis.ca List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 22:05:38 -0000 --e0cb4efe323e3e79d304d4b0f113 Content-Type: text/plain; charset=ISO-8859-1 Mike, On Fri, Feb 1, 2013 at 4:51 PM, mike amundsen wrote: > so, "action" is only for sending an empty HTTP.POST request; nothing else. > no other protocol use (XMPP, WS, FTP, etc.) no HTTP.PUT, PATCH, DELETE, or > any other method that might be added to HTTP in the future, correct? > > > If another protocol has an equivalent operation which is unsafe and requires no parameters, then I see no reason why there cannot be a mapping for that protocol. However, for HTTP the only other method I can imagine that might map is DELETE. However, that would then require the specification of a link-extension parameter to communicate what method to use. Personally, I would choose to limit it to POST. Darrel --e0cb4efe323e3e79d304d4b0f113 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Mike, --e0cb4efe323e3e79d304d4b0f113-- From mca@amundsen.com Fri Feb 1 14:18:12 2013 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 7231C21E804A for ; Fri, 1 Feb 2013 14:18:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.821 X-Spam-Level: X-Spam-Status: No, score=0.821 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FORGED_YAHOO_RCVD=2.297, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=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 aPmSHn8BJeUU for ; Fri, 1 Feb 2013 14:18:11 -0800 (PST) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by ietfa.amsl.com (Postfix) with ESMTP id 45DFC21E8049 for ; Fri, 1 Feb 2013 14:18:11 -0800 (PST) Received: by mail-wg0-f43.google.com with SMTP id e12so3192992wge.34 for ; Fri, 01 Feb 2013 14:18:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :x-gm-message-state; bh=EWLDVG/iSe71zukInZ6VjYXRLOgYaC+EnHy8C6GMfWA=; b=jjNcKjNuDURfraGmK+BGmSqFKfBqQ2zI8DNGUtYDXhDE3NeBRla+6OCL7/ydrkN4Q5 IeGocHsIQcB59HnIDLf4hMTpAwuq4OZCm2gxNcYRh+uhBgS9VF75yrptK/fqF4vKNdzB c3xX1n3hzYTZP7VutVEyN50DSPu4c/AvG3mvwpXOopxqskGnyI457OpG7yIy6dU5esPX wphRThZEiWDt+I1mRcVynpF+XNtUmVDDHbGplLn0XPiZGoCKtwiuueAIR22wLNj0rFp3 Asmbv/D93Vc3rMKm361lUCvCkoKrY225ei842vhWVtgGMOhSAYM3CpvBqhLQxfaoC1pK v1IA== X-Received: by 10.194.76.237 with SMTP id n13mr24437679wjw.57.1359757090229; Fri, 01 Feb 2013 14:18:10 -0800 (PST) MIME-Version: 1.0 Sender: mca@amundsen.com Received: by 10.194.166.36 with HTTP; Fri, 1 Feb 2013 14:17:50 -0800 (PST) In-Reply-To: References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> <-3128426172162859719@unknownmsgid> <022b01ce0085$a4452b90$eccf82b0$@tavis.ca> <6D2125B5-02DE-4016-86BA-38F8FA100DB4@nordsc.com> <3F268583-BC18-412F-8348-16AFB070EC21@nordsc.com> <694EDD73-FAB5-419E-B72D-717F5F7F21BF@nordsc.com> <7338D97E-0362-486B-AAF1-F9CD64813213@nordsc.com> <4522B945ABF34A74A39FCE1A0C68A9D2@gmail.com> From: mike amundsen Date: Fri, 1 Feb 2013 17:17:50 -0500 X-Google-Sender-Auth: ClQ9eGUi6uM-4e4F4PeiTxI3ZPU Message-ID: Subject: Re: NEW RELATION: action To: darrel@tavis.ca Content-Type: multipart/alternative; boundary=047d7bfcef74580d1004d4b11ed7 X-Gm-Message-State: ALoCoQlKtL9O0GEfB1N5sJuim/CYkCnW8m7XVL8vv9MuIhh4k5jsl5PORvoIt5qGDZAxB6Hfl5fZ Cc: link-relations , 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: Fri, 01 Feb 2013 22:18:12 -0000 --047d7bfcef74580d1004d4b11ed7 Content-Type: text/plain; charset=ISO-8859-1 1 - This describes a use-case that is pretty rare in my work (an unsafe, non-idempotent, empty request for a single protocol). 2 - It's not something I am likely to require in a media type design or in an instance implementation. And if I did, it would proly be an application-specific use-case; one that i'd solve within the available media types themselves. 3 - Most all media types i deal w/ allow this already and i don't see an advantage to create a rel value for it. 4 - I am not a fan of rel values that define protocol-level actions (e.g. methods) anyway. That's my view. mamund +1.859.757.1449 skype: mca.amundsen http://amundsen.com/blog/ http://twitter.com/mamund https://github.com/mamund http://www.linkedin.com/in/mikeamundsen On Fri, Feb 1, 2013 at 5:05 PM, Darrel Miller wrote: > Mike, > > On Fri, Feb 1, 2013 at 4:51 PM, mike amundsen wrote: > >> so, "action" is only for sending an empty HTTP.POST request; nothing >> else. no other protocol use (XMPP, WS, FTP, etc.) no HTTP.PUT, PATCH, >> DELETE, or any other method that might be added to HTTP in the future, >> correct? >> >> >> > If another protocol has an equivalent operation which is unsafe and > requires no parameters, then I see no reason why there cannot be a mapping > for that protocol. However, for HTTP the only other method I can imagine > that might map is DELETE. However, that would then require the > specification of a link-extension parameter to communicate what method to > use. Personally, I would choose to limit it to POST. > > Darrel > > --047d7bfcef74580d1004d4b11ed7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

1 - This describes a use-case that is pretty rare in my work= (an unsafe, non-idempotent, empty request for a single protocol).

=
2 - It's not something I am likely to require in a media typ= e design or in an instance implementation. And if I did, it would proly be = an application-specific use-case; one that i'd solve within the availab= le media types themselves.=A0

3 - Most all media types i deal w/ allow this already a= nd i don't see an advantage to create a rel value for it.
4 - I am not a fan of rel values that define protocol-level act= ions (e.g. methods) anyway.

That's my view.

On Fri, Feb 1, 2013 at 5:05 PM, Darrel M= iller <darrel.miller@gmail.com> wrote:
Mike,

On Fri, Feb 1, 2013 at 4:51 PM, mike amundsen <= span dir=3D"ltr"><= mamund@yahoo.com> wrote:
so, "action" is only for sending an empty HTTP.P= OST request; nothing else. no other protocol use (XMPP, WS, FTP, etc.) no H= TTP.PUT, PATCH, DELETE, or any other method that might be added to HTTP in = the future, correct?


If another protocol ha= s an equivalent operation which is unsafe and requires no parameters, then = =A0I see no reason why there cannot be a mapping for that protocol. =A0Howe= ver, for HTTP the only other method I can imagine that might map is DELETE.= =A0However, that would then require the specification of a link-extension = parameter to communicate what method to use. =A0Personally, I would choose = to limit it to POST.

Darrel=A0
=A0
=

--047d7bfcef74580d1004d4b11ed7-- From ioseb.dzmanashvili@gmail.com Fri Feb 1 14:45:59 2013 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 6930D21E8089 for ; Fri, 1 Feb 2013 14:45:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[AWL=-0.213, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=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 0MPGWUtnaUuA for ; Fri, 1 Feb 2013 14:45:58 -0800 (PST) Received: from mail-ee0-f48.google.com (mail-ee0-f48.google.com [74.125.83.48]) by ietfa.amsl.com (Postfix) with ESMTP id AAB9221E8083 for ; Fri, 1 Feb 2013 14:45:57 -0800 (PST) Received: by mail-ee0-f48.google.com with SMTP id t10so2239520eei.7 for ; Fri, 01 Feb 2013 14:45:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:message-id:in-reply-to:references :subject:x-mailer:mime-version:content-type; bh=zEpFrIYnhx7wHaKqhmX6lIKU80cZngvXA+++8IxV2Gc=; b=N3hkcl/tebriLxwc/Z+MbuJhHo+47OZxZXHwr69gPcv9Q7U1zPxUBE8qGjF9uVp5Vl kXKIziIAivzj854s6lSQOw/HYJDYIHjw5A3eYQkvRgRM+kNvcwq5cZryS4P+ioS9ZX2D kz2Vrf2//uhteb6bdB5GSjHHl0qSatHdwyoO7taQ6m1Ep0a+4umtA964d1m0INdImN91 MvVretG6lbLnKzwRcGEnLWRAe1457+XHGSexlXgMrUjZEXsj/RBGhxIbnZQSwNELztzr rB5q0IfiJCHKTZGOpw5G/hZOiy8aF5PJgerjlTh4+A3o530LnwA7UUG55+BkxcppAYJs jtxA== X-Received: by 10.14.4.194 with SMTP id 42mr44412190eej.35.1359758756812; Fri, 01 Feb 2013 14:45:56 -0800 (PST) Received: from [192.168.1.3] ([176.73.174.236]) by mx.google.com with ESMTPS id 44sm14729736eek.5.2013.02.01.14.45.54 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 01 Feb 2013 14:45:55 -0800 (PST) Date: Sat, 2 Feb 2013 02:45:54 +0400 From: Ioseb Dzmanashvili To: mike amundsen Message-ID: <680DF765108749568E54174961CF84C6@gmail.com> In-Reply-To: References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> <-3128426172162859719@unknownmsgid> <022b01ce0085$a4452b90$eccf82b0$@tavis.ca> <6D2125B5-02DE-4016-86BA-38F8FA100DB4@nordsc.com> <3F268583-BC18-412F-8348-16AFB070EC21@nordsc.com> <694EDD73-FAB5-419E-B72D-717F5F7F21BF@nordsc.com> <7338D97E-0362-486B-AAF1-F9CD64813213@nordsc.com> <4522B945ABF34A74A39FCE1A0C68A9D2@gmail.com> Subject: Re: NEW RELATION: action X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="510c45a2_7b6c7dc6_28a" Cc: darrel@tavis.ca, link-relations 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, 01 Feb 2013 22:45:59 -0000 --510c45a2_7b6c7dc6_28a Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Mike, > 2 - It's not something I am likely to require in a media type design or in an instance implementation. And if I did, it would proly be an application-specific use-case; one that i'd solve within the available media types themselves. The approach i'm trying to defend doesn't require media type(s), message constructions etc... There are a lot of use cases where such kind of simple interactions just work and most of the interaction can be carried with simple HTTP messages + Link header field. This is the point of this link rel, not that it's impossible to implement such functionality with existing media types. > 3 - Most all media types i deal w/ allow this already and i don't see an advantage to create a rel value for it. Can you please point me to such media type which allows to implement similar functionality single-handedly? (i'm really interested). > That's my view. Thanks! :-) Cheers, ioseb On Saturday, February 2, 2013 at 2:17 AM, mike amundsen wrote: > > 1 - This describes a use-case that is pretty rare in my work (an unsafe, non-idempotent, empty request for a single protocol). > > 2 - It's not something I am likely to require in a media type design or in an instance implementation. And if I did, it would proly be an application-specific use-case; one that i'd solve within the available media types themselves. > > 3 - Most all media types i deal w/ allow this already and i don't see an advantage to create a rel value for it. > > 4 - I am not a fan of rel values that define protocol-level actions (e.g. methods) anyway. > > That's my view. > > mamund > +1.859.757.1449 > skype: mca.amundsen > http://amundsen.com/blog/ > http://twitter.com/mamund > https://github.com/mamund > http://www.linkedin.com/in/mikeamundsen > > On Fri, Feb 1, 2013 at 5:05 PM, Darrel Miller wrote: > > Mike, > > > > On Fri, Feb 1, 2013 at 4:51 PM, mike amundsen wrote: > > > so, "action" is only for sending an empty HTTP.POST request; nothing else. no other protocol use (XMPP, WS, FTP, etc.) no HTTP.PUT, PATCH, DELETE, or any other method that might be added to HTTP in the future, correct? > > > > > > > If another protocol has an equivalent operation which is unsafe and requires no parameters, then I see no reason why there cannot be a mapping for that protocol. However, for HTTP the only other method I can imagine that might map is DELETE. However, that would then require the specification of a link-extension parameter to communicate what method to use. Personally, I would choose to limit it to POST. > > > > Darrel > > > > > > > > > > > > > > > --510c45a2_7b6c7dc6_28a Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Mike,

> 2 - It's no= t something I am likely to require in a media type design or in an instan= ce implementation. And if I did, it would proly be an application-specifi= c use-case; one that i'd solve within the available media types themselve= s. 

The approach i'm trying to defend doesn= 't require media type(s), message constructions etc... There are a lot of= use cases where such kind of simple interactions just work and most of t= he interaction can be carried with simple HTTP messages + Link header fie= ld. This is the point of this link rel, not that it's impossible to imple= ment such functionality with existing media types.

> 3 - Most all media types i deal w/ allow this already and i don't= see an advantage to create a rel value for it.

= Can you please point me to such media type which allows to implement simi= lar functionality single-handedly=3F (i'm really interested).
<= br>
> That's my view.

Thanks=21 :-)=

Cheers,
ioseb
=20

On Saturday, =46ebruar= y 2, 2013 at 2:17 AM, mike amundsen wrote:


1 - This describes a u= se-case that is pretty rare in my work (an unsafe, non-idempotent, empty = request for a single protocol).

2 - It's not something= I am likely to require in a media type design or in an instance implemen= tation. And if I did, it would proly be an application-specific use-case;= one that i'd solve within the available media types themselves. 

3 - Most all media types i deal w/ allow this already= and i don't see an advantage to create a rel value for it.
4 - I am not a fan of rel values that define protocol-level a= ctions (e.g. methods) anyway.

That's my view.



On =46ri, =46eb 1, 2013 at 5:05 PM, Darrel Miller <darrel.miller=40gmail.com> wrote:
Mike,

On =46ri, =46eb 1, 2013= at 4:51 PM, mike amundsen <mamund=40yahoo.com><= /span> wrote:
so, =22action=22 is o= nly for sending an empty HTTP.POST request; nothing else. no other protoc= ol use (XMPP, WS, =46TP, etc.) no HTTP.PUT, PATCH, DELETE, or any other m= ethod that might be added to HTTP in the future, correct=3F

If anoth= er protocol has an equivalent operation which is unsafe and requires no p= arameters, then  I see no reason why there cannot be a mapping for t= hat protocol.  However, for HTTP the only other method I can imagine= that might map is DELETE.  However, that would then require the spe= cification of a link-extension parameter to communicate what method to us= e.  Personally, I would choose to limit it to POST.

Darrel 
 

=20 =20 =20 =20 =20

--510c45a2_7b6c7dc6_28a-- From mca@amundsen.com Fri Feb 1 15:13:48 2013 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 83CB91F0CFC for ; Fri, 1 Feb 2013 15:13:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.121 X-Spam-Level: * X-Spam-Status: No, score=1.121 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FORGED_YAHOO_RCVD=2.297, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=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 BOgNOjf6kRRF for ; Fri, 1 Feb 2013 15:13:46 -0800 (PST) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) by ietfa.amsl.com (Postfix) with ESMTP id 05CF11F0C4A for ; Fri, 1 Feb 2013 15:13:44 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id hn14so1147832wib.10 for ; Fri, 01 Feb 2013 15:13:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :x-gm-message-state; bh=NlCLaeARD4Golvk59uP+vSLEj+yq8uZayzSNrU800ps=; b=GYIXvGFqsBFwxO7U+/DzsohZE8u/u5LcjjAXDSN8ujvmMtxkGd3SIh+vll/mTwomRK EAgLhlG9TTaIvP+Cn4st7ByI1Pf//liYCjWRTIjd0rshR9FUTouh9L9jJLFv29nzY6jc A1BjyGzMRdQxZzF8kO779au4I2EE4zGO8XaSgCsvq4U0ZpJt7WIX9ZZaqdI7e4+jjvIF 51uVMxV62KKqRP9BvBTYAG+xQi4NDGSF3bki2ctswTlWECsP6XKJMx7aKmco9RQLW2TY Zg7XrEfbA3ZMN+3UIMWrPhH25faLekQqDoC8pgWw7erPG4HzSS3uFJMx+SPZrjaobkxs EAOA== X-Received: by 10.194.76.237 with SMTP id n13mr24597853wjw.57.1359760424096; Fri, 01 Feb 2013 15:13:44 -0800 (PST) MIME-Version: 1.0 Sender: mca@amundsen.com Received: by 10.194.166.36 with HTTP; Fri, 1 Feb 2013 15:13:23 -0800 (PST) In-Reply-To: <680DF765108749568E54174961CF84C6@gmail.com> References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> <-3128426172162859719@unknownmsgid> <022b01ce0085$a4452b90$eccf82b0$@tavis.ca> <6D2125B5-02DE-4016-86BA-38F8FA100DB4@nordsc.com> <3F268583-BC18-412F-8348-16AFB070EC21@nordsc.com> <694EDD73-FAB5-419E-B72D-717F5F7F21BF@nordsc.com> <7338D97E-0362-486B-AAF1-F9CD64813213@nordsc.com> <4522B945ABF34A74A39FCE1A0C68A9D2@gmail.com> <680DF765108749568E54174961CF84C6@gmail.com> From: mike amundsen Date: Fri, 1 Feb 2013 18:13:23 -0500 X-Google-Sender-Auth: mqA0gVMYQoajRl7G5q7pHzLmwkI Message-ID: Subject: Re: NEW RELATION: action To: Ioseb Dzmanashvili Content-Type: multipart/alternative; boundary=047d7bfcef740ed31804d4b1e50b X-Gm-Message-State: ALoCoQn6K9sFhZJo3NkkUefDls54Ot4Qs315WtCsdC7ryMKwz2UK31cw792oWuiFXoWNNfCZoCam Cc: darrel@tavis.ca, link-relations 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, 01 Feb 2013 23:13:48 -0000 --047d7bfcef740ed31804d4b1e50b Content-Type: text/plain; charset=ISO-8859-1 On Fri, Feb 1, 2013 at 5:45 PM, Ioseb Dzmanashvili < ioseb.dzmanashvili@gmail.com> wrote: > Mike, > > > 2 - It's not something I am likely to require in a media type design or > in an instance implementation. And if I did, it would proly be an > application-specific use-case; one that i'd solve within the available > media types themselves. > > The approach i'm trying to defend doesn't require media type(s), message > constructions etc... There are a lot of use cases where such kind of simple > interactions just work and most of the interaction can be carried with > simple HTTP messages + Link header field. This is the point of this link > rel, not that it's impossible to implement such functionality with existing > media types. > well "there are lots" is most likely an exercise of availability bias :) I am telling you here that "It's not something *I* am likely to require..." not making a statement about your work or anyone else's work. "simple HTTP messages" is also not quantifiable. I have no doubt you like this design; might even find it to be "simple" I'm not saying it's "not simple." maybe you have another thing in mind for "simple" that i'm not getting here. We agree "it's not impossible... with existing media types" - no problem there. > > 3 - Most all media types i deal w/ allow this already and i don't see an > advantage to create a rel value for it. > > Can you please point me to such media type which allows to implement > similar functionality single-handedly? (i'm really interested). > "single-handedly" is something I can't comment upon since i don't know what you mean here. however, i can describe an "empty POST" in HTML, HAL, Cj, and Siren; proly voiceXML, too. Atom doesn't support any variable definitions for unsafe transitions (empty or otherwise), but OData's CDSL allows me to describe an empty POST. > > > That's my view. > > Thanks! :-) > > Cheers, > ioseb > > On Saturday, February 2, 2013 at 2:17 AM, mike amundsen wrote: > > > 1 - This describes a use-case that is pretty rare in my work (an unsafe, > non-idempotent, empty request for a single protocol). > > 2 - It's not something I am likely to require in a media type design or in > an instance implementation. And if I did, it would proly be an > application-specific use-case; one that i'd solve within the available > media types themselves. > > 3 - Most all media types i deal w/ allow this already and i don't see an > advantage to create a rel value for it. > > 4 - I am not a fan of rel values that define protocol-level actions (e.g. > methods) anyway. > > That's my view. > > mamund > +1.859.757.1449 > skype: mca.amundsen > http://amundsen.com/blog/ > http://twitter.com/mamund > https://github.com/mamund > http://www.linkedin.com/in/mikeamundsen > > > On Fri, Feb 1, 2013 at 5:05 PM, Darrel Miller wrote: > > Mike, > > On Fri, Feb 1, 2013 at 4:51 PM, mike amundsen wrote: > > so, "action" is only for sending an empty HTTP.POST request; nothing else. > no other protocol use (XMPP, WS, FTP, etc.) no HTTP.PUT, PATCH, DELETE, or > any other method that might be added to HTTP in the future, correct? > > > > If another protocol has an equivalent operation which is unsafe and > requires no parameters, then I see no reason why there cannot be a mapping > for that protocol. However, for HTTP the only other method I can imagine > that might map is DELETE. However, that would then require the > specification of a link-extension parameter to communicate what method to > use. Personally, I would choose to limit it to POST. > > Darrel > > > > > --047d7bfcef740ed31804d4b1e50b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Feb 1, 2013 at 5:45 PM, Ioseb Dzmanashvili <ioseb.dzman= ashvili@gmail.com> wrote:
Mike,

= > 2 - It's not something I am likely to require in a media type desi= gn or in an instance implementation. And if I did, it would proly be an app= lication-specific use-case; one that i'd solve within the available med= ia types themselves.=A0

The approach i'm trying to defend doesn't= require media type(s), message constructions etc... There are a lot of use= cases where such kind of simple interactions just work and most of the int= eraction can be carried with simple HTTP messages + Link header field. This= is the point of this link rel, not that it's impossible to implement s= uch functionality with existing media types.

well "there are lots" is m= ost likely an exercise of availability bias :) I am telling you here that &= quot;It's not something *I* am likely to require..." not making a = statement about your work or anyone else's work.

"simple HTTP messages" is also not quantifiab= le. I have no doubt you like this design; might even find it to be "si= mple" I'm not saying it's "not simple." maybe you ha= ve another thing in mind for "simple" that i'm not getting he= re.

We agree "it's not impossible... with existing= media types" - no problem there.


> 3 - Most all media types i = deal w/ allow this already and i don't see an advantage to create a rel= value for it.

Can you please point me to su= ch media type which allows to implement similar functionality single-handed= ly? (i'm really interested).
"single-handedly" is something I can'= t comment upon since i don't know what you mean here.=A0

=
however, i can describe an "empty POST" in HTML, HAL, = Cj, and Siren; proly voiceXML, too. Atom doesn't support any variable= =A0definitions for unsafe transitions=A0(empty or otherwise), but OData'= ;s CDSL allows me to=A0describe=A0an empty POST.
=A0

> = That's my view.

Thanks! :-)

Cheers,
i= oseb
=20

On Saturday, February 2, 2013 at= 2:17 AM, mike amundsen wrote:


1 - This describes a use= -case that is pretty rare in my work (an unsafe, non-idempotent, empty requ= est for a single protocol).

2 - It's not something I= am likely to require in a media type design or in an instance implementati= on. And if I did, it would proly be an application-specific use-case; one t= hat i'd solve within the available media types themselves.=A0

3 - Most all media types i deal w/ allow this already a= nd i don't see an advantage to create a rel value for it.
4 - I am not a fan of rel values that define protocol-level act= ions (e.g. methods) anyway.

That's my view.



On Fri, Feb 1, 2013 at 5:05 PM, Darrel Miller <darrel.m= iller@gmail.com> wrote:
Mike,

On Fri, Feb 1, 2013 at 4:51 P= M, mike amundsen <mamund@yahoo.com> wrote:
so, "action" is only for sending an empty HTTP.POST request;= nothing else. no other protocol use (XMPP, WS, FTP, etc.) no HTTP.PUT, PAT= CH, DELETE, or any other method that might be added to HTTP in the future, = correct?


If another proto= col has an equivalent operation which is unsafe and requires no parameters,= then =A0I see no reason why there cannot be a mapping for that protocol. = =A0However, for HTTP the only other method I can imagine that might map is = DELETE. =A0However, that would then require the specification of a link-ext= ension parameter to communicate what method to use. =A0Personally, I would = choose to limit it to POST.

Darrel=A0
=A0
=

=20 =20 =20 =20
=20


--047d7bfcef740ed31804d4b1e50b-- From ioseb.dzmanashvili@gmail.com Fri Feb 1 15:44:23 2013 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 AB5D721E804A for ; Fri, 1 Feb 2013 15:44:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.687 X-Spam-Level: X-Spam-Status: No, score=-1.687 tagged_above=-999 required=5 tests=[AWL=-0.489, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_55=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 7hX+8Nv-1WCJ for ; Fri, 1 Feb 2013 15:44:22 -0800 (PST) Received: from mail-ee0-f46.google.com (mail-ee0-f46.google.com [74.125.83.46]) by ietfa.amsl.com (Postfix) with ESMTP id 10A2A11E8097 for ; Fri, 1 Feb 2013 15:44:21 -0800 (PST) Received: by mail-ee0-f46.google.com with SMTP id e49so2344333eek.19 for ; Fri, 01 Feb 2013 15:44:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:message-id:in-reply-to:references :subject:x-mailer:mime-version:content-type; bh=5maPYTkcrdH8tK8MTaffr7+xfLOVA0+Z9cXwkxcS8KQ=; b=a3u6bU1US+5KUpBC0oEHtImKxDZIwBmK5pXJojOf3XZE4HQzC8EGj7deRrBmqLk64V tiicxqLX6bicC2dU0y+UwM1zLg3aC1t8Y6RHA1KqeWs/lMvkproW9Hsspsj3h3aTkbBw Q9kmR9gKJzsEzsT5hSP1Lg2Y2xuXTuA4TjnzLoclfsRD/fIiK1kjHCyB6tRRwIc3ZBqm YZ2k2ta1FclEVy+AGK4RV+Fv2FjT/uiqhPaPxkkNY+ajxaiJ5wHrheqdkSqOMGuD4ssX T0hh1XbxRR36phMiLB6dkGUfIDKGOEmYyqT9No2Cz2yNZG/EbgkJnO/X+1clEBlI+crG rtEA== X-Received: by 10.14.219.6 with SMTP id l6mr2982095eep.23.1359762261209; Fri, 01 Feb 2013 15:44:21 -0800 (PST) Received: from [192.168.1.3] ([176.73.174.236]) by mx.google.com with ESMTPS id o3sm14900374eem.15.2013.02.01.15.44.18 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 01 Feb 2013 15:44:19 -0800 (PST) Date: Sat, 2 Feb 2013 03:44:18 +0400 From: Ioseb Dzmanashvili To: mike amundsen Message-ID: In-Reply-To: References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> <-3128426172162859719@unknownmsgid> <022b01ce0085$a4452b90$eccf82b0$@tavis.ca> <6D2125B5-02DE-4016-86BA-38F8FA100DB4@nordsc.com> <3F268583-BC18-412F-8348-16AFB070EC21@nordsc.com> <694EDD73-FAB5-419E-B72D-717F5F7F21BF@nordsc.com> <7338D97E-0362-486B-AAF1-F9CD64813213@nordsc.com> <4522B945ABF34A74A39FCE1A0C68A9D2@gmail.com> <680DF765108749568E54174961CF84C6@gmail.com> Subject: Re: NEW RELATION: action X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="510c5352_39112b90_28a" Cc: darrel@tavis.ca, link-relations 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, 01 Feb 2013 23:44:23 -0000 --510c5352_39112b90_28a Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Mike, > "simple HTTP messages" is also not quantifiable. I have no doubt you like this design; might even find it to be "simple" I'm not saying it's "not simple." maybe you have another thing in mind for "simple" that i'm not getting here. Well, what i mean under "simple" is this: having link relation type like "action" which has very clear and simple purpose(i.e. send an empty POST request to this URI), it's very easy to filter out these "action" links from bunch of other links and present to the application user contextually(i.e. actions available alongside list items, window/page/screen level actions etc...) without need to rely on: * Application level semantics which are described in underlying media type; * Application specific conventions; * Additional documentation; * Some other assumptions; * etc... As i see it it's mostly useful for applications where users are involved and less valuable for M2M interactions(though it's possible too). Under "simple HTTP messages" i mean that HTTP headers and status codes could be enough in lots of cases. > "single-handedly" is something I can't comment upon since i don't know what you mean here. Sorry for confusion, i meant without involving media types help to describe such kind of interactions. > however, i can describe an "empty POST" in HTML, HAL, Cj, and Siren; proly voiceXML, too. Atom doesn't support any variable definitions for unsafe transitions (empty or otherwise), but OData's CDSL allows me to describe an empty POST. I do not argue that it's not possible with mentioned formats, and to be honest i do it all time. Though there are some cons when using these media types for describing these unsafe interactions. To be clear, HTML allows us to construct messages the way we want(i.e. inline empty forms, links, data...), this format is very well understood by browsers and can be rendered properly according to its structure. On the other hand not HAL nor Cj have such possibilities(i.e rendering). These formats do not offer such possibility to directly embed multiple "forms" for constructing empty POST requests. Even it's achievable it doesn't clearly say how to distinguish such elements from the document. Whereas links(which both formats support fantastically) could be easily distinguished and grouped from others by rel values and presented contextually to users. Again, it's not that there is no possibility for doing such things but in my opinion it's not that simple and clear. Best regards, ioseb On Saturday, February 2, 2013 at 3:13 AM, mike amundsen wrote: > On Fri, Feb 1, 2013 at 5:45 PM, Ioseb Dzmanashvili wrote: > > Mike, > > > > > 2 - It's not something I am likely to require in a media type design or in an instance implementation. And if I did, it would proly be an application-specific use-case; one that i'd solve within the available media types themselves. > > > > The approach i'm trying to defend doesn't require media type(s), message constructions etc... There are a lot of use cases where such kind of simple interactions just work and most of the interaction can be carried with simple HTTP messages + Link header field. This is the point of this link rel, not that it's impossible to implement such functionality with existing media types. > > well "there are lots" is most likely an exercise of availability bias :) I am telling you here that "It's not something *I* am likely to require..." not making a statement about your work or anyone else's work. > > "simple HTTP messages" is also not quantifiable. I have no doubt you like this design; might even find it to be "simple" I'm not saying it's "not simple." maybe you have another thing in mind for "simple" that i'm not getting here. > > We agree "it's not impossible... with existing media types" - no problem there. > > > > > > 3 - Most all media types i deal w/ allow this already and i don't see an advantage to create a rel value for it. > > > > Can you please point me to such media type which allows to implement similar functionality single-handedly? (i'm really interested). > "single-handedly" is something I can't comment upon since i don't know what you mean here. > > however, i can describe an "empty POST" in HTML, HAL, Cj, and Siren; proly voiceXML, too. Atom doesn't support any variable definitions for unsafe transitions (empty or otherwise), but OData's CDSL allows me to describe an empty POST. > > > > > > That's my view. > > > > Thanks! :-) > > > > Cheers, > > ioseb > > > > > > On Saturday, February 2, 2013 at 2:17 AM, mike amundsen wrote: > > > > > > > > 1 - This describes a use-case that is pretty rare in my work (an unsafe, non-idempotent, empty request for a single protocol). > > > > > > 2 - It's not something I am likely to require in a media type design or in an instance implementation. And if I did, it would proly be an application-specific use-case; one that i'd solve within the available media types themselves. > > > > > > 3 - Most all media types i deal w/ allow this already and i don't see an advantage to create a rel value for it. > > > > > > 4 - I am not a fan of rel values that define protocol-level actions (e.g. methods) anyway. > > > > > > That's my view. > > > > > > mamund > > > +1.859.757.1449 (tel:%2B1.859.757.1449) > > > skype: mca.amundsen > > > http://amundsen.com/blog/ > > > http://twitter.com/mamund > > > https://github.com/mamund > > > http://www.linkedin.com/in/mikeamundsen > > > > > > On Fri, Feb 1, 2013 at 5:05 PM, Darrel Miller wrote: > > > > Mike, > > > > > > > > On Fri, Feb 1, 2013 at 4:51 PM, mike amundsen wrote: > > > > > so, "action" is only for sending an empty HTTP.POST request; nothing else. no other protocol use (XMPP, WS, FTP, etc.) no HTTP.PUT, PATCH, DELETE, or any other method that might be added to HTTP in the future, correct? > > > > > > > > > > > > > If another protocol has an equivalent operation which is unsafe and requires no parameters, then I see no reason why there cannot be a mapping for that protocol. However, for HTTP the only other method I can imagine that might map is DELETE. However, that would then require the specification of a link-extension parameter to communicate what method to use. Personally, I would choose to limit it to POST. > > > > > > > > Darrel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --510c5352_39112b90_28a Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Mike,

> =22simple H= TTP messages=22 is also not quantifiable. I have no doubt you like this d= esign; might even find it to be =22simple=22 I'm not saying it's =22not s= imple.=22 maybe you have another thing in mind for =22simple=22 that i'm = not getting here.

Well, what i mean under =22sim= ple=22 is this: having link relation type like =22action=22 which has ver= y clear and simple purpose(i.e. send an empty POST request to this URI), = it's very easy to filter out these =22action=22 links from bunch of other= links and present to the application user contextually(i.e. actions avai= lable alongside list items, window/page/screen level actions etc...) with= out need to rely on:

* Application level semanti= cs which are described in underlying media type;
* Application = specific conventions;
* Additional documentation;
* S= ome other assumptions;
* etc...

As i s= ee it it's mostly useful for applications where users are involved and le= ss valuable for M2M interactions(though it's possible too).
Under =22simple HTTP messages=22 i mean that HTTP headers and= status codes could be enough in lots of cases.

= > =22single-handedly=22 is something I can't comment upon since i don'= t know what you mean here.

Sorry for confusion, = i meant without involving media types help to describe such kind of inter= actions.

> however, i can describe an =22empt= y POST=22 in HTML, HAL, Cj, and Siren; proly voiceXML, too. Atom doesn't = support any variable definitions for unsafe transitions (empty or otherwi= se), but OData's CDSL allows me to describe an empty POST.

=
I do not argue that it's not possible with mentioned formats, = and to be honest i do it all time. Though there are some cons when using = these media types for describing these unsafe interactions. To be clear, = HTML allows us to construct messages the way we want(i.e. inline empty fo= rms, links, data...), this format is very well understood by browsers and= can be rendered properly according to its structure. 
On the other hand not HAL nor Cj have such possibilities(i.e = rendering). These formats do not offer such possibility to directly embed= multiple =22forms=22 for constructing empty POST requests. Even it's ach= ievable it doesn't clearly say how to distinguish such elements from the = document. Whereas links(which both formats support fantastically) could b= e easily distinguished and grouped from others by rel values and presente= d contextually to users.

Again, it's not that th= ere is no possibility for doing such things but in my opinion it's not th= at simple and clear.

Best regards,
ios= eb


=20

On Saturday, =46ebruar= y 2, 2013 at 3:13 AM, mike amundsen wrote:

On =46ri, =46eb 1, 2013 at 5:45 PM, I= oseb Dzmanashvili <ioseb.dzmanashvili=40gma= il.com> wrote:
Mike,

> 2 - It= 's not something I am likely to require in a media type design or in an i= nstance implementation. And if I did, it would proly be an application-sp= ecific use-case; one that i'd solve within the available media types them= selves. 

The approach i'm trying to defend doesn't requi= re media type(s), message constructions etc... There are a lot of use cas= es where such kind of simple interactions just work and most of the inter= action can be carried with simple HTTP messages + Link header field. This= is the point of this link rel, not that it's impossible to implement suc= h functionality with existing media types.

well =22there are lots=22 is= most likely an exercise of availability bias :) I am telling you here th= at =22It's not something *I* am likely to require...=22 not making a stat= ement about your work or anyone else's work.

=22simple HTTP messages=22 is also not quantifiable. = I have no doubt you like this design; might even find it to be =22simple=22= I'm not saying it's =22not simple.=22 maybe you have another thing in mi= nd for =22simple=22 that i'm not getting here.

We agree =22it's not impossible... with existing medi= a types=22 - no problem there.


> 3 - Most all media types i deal w/ all= ow this already and i don't see an advantage to create a rel value for it= .

Can you please point me to such media ty= pe which allows to implement similar functionality single-handedly=3F (i'= m really interested).
=22single-handedly=22 is something I can't = comment upon since i don't know what you mean here. 

<= /div>
however, i can describe an =22empty POST=22 in HTML, HAL, Cj, a= nd Siren; proly voiceXML, too. Atom doesn't support any variable def= initions for unsafe transitions (empty or otherwise), but OData's CD= SL allows me to describe an empty POST.
 

> That's my= view.

Thanks=21 :-)
<= br>
Cheers,
ioseb
=20

On Saturday, =46ebruary = 2, 2013 at 2:17 AM, mike amundsen wrote:


1 - This describes a u= se-case that is pretty rare in my work (an unsafe, non-idempotent, empty = request for a single protocol).

2 - It's not something= I am likely to require in a media type design or in an instance implemen= tation. And if I did, it would proly be an application-specific use-case;= one that i'd solve within the available media types themselves. 

3 - Most all media types i deal w/ allow this already= and i don't see an advantage to create a rel value for it.
4 - I am not a fan of rel values that define protocol-level a= ctions (e.g. methods) anyway.

That's my view.



On =46ri, =46eb 1, 2013 at 5:05 PM, Darrel Miller <darrel.miller=40gmail.com> wrote:
Mike,

On =46ri, =46eb 1, 2013= at 4:51 PM, mike amundsen <mamund=40yahoo.com><= /span> wrote:
so, =22action=22 is only for sending an empty HTTP.POST request; not= hing else. no other protocol use (XMPP, WS, =46TP, etc.) no HTTP.PUT, PAT= CH, DELETE, or any other method that might be added to HTTP in the future= , correct=3F

If= another protocol has an equivalent operation which is unsafe and require= s no parameters, then  I see no reason why there cannot be a mapping= for that protocol.  However, for HTTP the only other method I can i= magine that might map is DELETE.  However, that would then require t= he specification of a link-extension parameter to communicate what method= to use.  Personally, I would choose to limit it to POST.

Darrel 
 

=20 =20 =20 =20


=20 =20 =20 =20 =20

--510c5352_39112b90_28a-- From darrel.miller@gmail.com Fri Feb 1 15:45:17 2013 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 7CC7E21E804E for ; Fri, 1 Feb 2013 15:45:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.254 X-Spam-Level: X-Spam-Status: No, score=-3.254 tagged_above=-999 required=5 tests=[AWL=0.344, 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 o+XWNDmdl2c8 for ; Fri, 1 Feb 2013 15:45:11 -0800 (PST) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) by ietfa.amsl.com (Postfix) with ESMTP id 0586621E8041 for ; Fri, 1 Feb 2013 15:45:10 -0800 (PST) Received: by mail-lb0-f176.google.com with SMTP id s4so5002097lbc.21 for ; Fri, 01 Feb 2013 15:45:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=AjauQDrgAnpwmi83j1Cq3fKsOCMxPVwrJtvE9GIkYq0=; b=YAfMqliG14N4jugP+4v+4Qkv00j/Lv/a6s69w/zg69aK7bck3GjkxCIn+pV3Wv7veH PvccV33AakEZK1mcoZk6eLhBGC/3c6didSj+imYcXJTC30BxKyQUrdWXI82wHdMcGuBF DlQa6qADG5Mep4n3enxb4vOf885DCD5Y4ZUYN9Kyh0nWFAc4N/aXBFv0wBekX2ymaC45 leiaOfdu1m5uS3THBGnLYsd61E2IYa9ycqdryYg4R/hGZo9pv+/c8Rr1bBmwRckKoF4B xlv0DgwBlW7mBoVmP8MgQKXN2Gn4YOlyIChsRGtci5ANd3TY617t6sW4FCcw9Fb4e/pW dz9w== MIME-Version: 1.0 X-Received: by 10.152.105.17 with SMTP id gi17mr12521903lab.46.1359762309819; Fri, 01 Feb 2013 15:45:09 -0800 (PST) Received: by 10.152.109.204 with HTTP; Fri, 1 Feb 2013 15:45:09 -0800 (PST) In-Reply-To: References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> <-3128426172162859719@unknownmsgid> <022b01ce0085$a4452b90$eccf82b0$@tavis.ca> <6D2125B5-02DE-4016-86BA-38F8FA100DB4@nordsc.com> <3F268583-BC18-412F-8348-16AFB070EC21@nordsc.com> <694EDD73-FAB5-419E-B72D-717F5F7F21BF@nordsc.com> <7338D97E-0362-486B-AAF1-F9CD64813213@nordsc.com> <4522B945ABF34A74A39FCE1A0C68A9D2@gmail.com> <680DF765108749568E54174961CF84C6@gmail.com> Date: Fri, 1 Feb 2013 18:45:09 -0500 Message-ID: Subject: Re: NEW RELATION: action From: Darrel Miller To: mike amundsen Content-Type: multipart/alternative; boundary=f46d040892fd74aeb104d4b255cc Cc: link-relations , Ioseb Dzmanashvili X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: darrel@tavis.ca List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 23:45:17 -0000 --f46d040892fd74aeb104d4b255cc Content-Type: text/plain; charset=ISO-8859-1 Mike, On Fri, Feb 1, 2013 at 6:13 PM, mike amundsen wrote: > > however, i can describe an "empty POST" in HTML, HAL, Cj, and Siren; proly > voiceXML, too. Atom doesn't support any variable definitions for unsafe > transitions (empty or otherwise), but OData's CDSL allows me to describe an > empty POST. > > Unless, Mr. Kelly did some magic on HAL while I wasn't looking there is nothing in the media type that allows you to include hypermedia controls for unsafe interactions without deferring to a link relation. Also, OData has also come to the same conclusion that the concept of an "action" is necessary, which is why they invented OData "Actions". http://www.odata.org/blog/2011/10/7/actions-in-odata Darrel --f46d040892fd74aeb104d4b255cc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Mike,

On Fri, Feb 1, 2013 at 6:13 PM, m= ike amundsen <mamund@yahoo.com> wrote:

however, i can describe an "empty POST" in HTML, HAL, Cj, and S= iren; proly voiceXML, too. Atom doesn't support any variable=A0definiti= ons for unsafe transitions=A0(empty or otherwise), but OData's CDSL all= ows me to=A0describe=A0an empty POST.
=A0

Unless, Mr= . Kelly did some magic on HAL while I wasn't looking there is nothing i= n the media type that allows you to include hypermedia controls for unsafe = interactions without deferring to a link relation.

Also, OData has also come to the same concl= usion that the concept of an "action" is necessary, which is why = they invented OData "Actions". =A0http://www.odata.org/blog/2011/10/7/actio= ns-in-odata


Darrel


=A0
--f46d040892fd74aeb104d4b255cc-- From mca@amundsen.com Fri Feb 1 15:47:44 2013 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 48D9621E8041 for ; Fri, 1 Feb 2013 15:47:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.321 X-Spam-Level: X-Spam-Status: No, score=0.321 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FORGED_YAHOO_RCVD=2.297, HTML_MESSAGE=0.001, J_CHICKENPOX_38=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 3L1RbYCh8w7r for ; Fri, 1 Feb 2013 15:47:43 -0800 (PST) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by ietfa.amsl.com (Postfix) with ESMTP id A611E21F88EE for ; Fri, 1 Feb 2013 15:47:10 -0800 (PST) Received: by mail-wg0-f45.google.com with SMTP id dq12so3401912wgb.24 for ; Fri, 01 Feb 2013 15:47:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :x-gm-message-state; bh=l+213n4cNt2rmNv/9K3wGnmuguF5R+2fi5X3O7motu4=; b=meVwEjcuVkSi4CLIc4JLJ6ea3IngvmbCJEPnpsQ8BTWWB6A0dR1heAWehT8OEneo+K SjsIFz0EUo6eHmtNqJJanLP0rQvPp4KdAwhywE/vxwyIzskIyS1NqBkjiM7pLzAH1s6J d+6hk3PQpi8krlRPzaJKE9mlv1lc1syFMrrPXtNMcKI5Y+eKKHiZ3H7aqUlf5FMPn+q7 /LkJNxCUNNuV6mDw8aG3avV2cEnzviaVz+0ftZJOhYANE6HLbETdd/4qhlceyac47FTd 7Mjy9VNX0nChFlxG8Elolcw8BeufEjHdrwtx5sEzEwO2pZJVAI4bN1bK4NkGhAVuWdvR 8G4g== X-Received: by 10.194.76.165 with SMTP id l5mr24565438wjw.14.1359762429653; Fri, 01 Feb 2013 15:47:09 -0800 (PST) MIME-Version: 1.0 Sender: mca@amundsen.com Received: by 10.194.166.36 with HTTP; Fri, 1 Feb 2013 15:46:49 -0800 (PST) In-Reply-To: References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> <-3128426172162859719@unknownmsgid> <022b01ce0085$a4452b90$eccf82b0$@tavis.ca> <6D2125B5-02DE-4016-86BA-38F8FA100DB4@nordsc.com> <3F268583-BC18-412F-8348-16AFB070EC21@nordsc.com> <694EDD73-FAB5-419E-B72D-717F5F7F21BF@nordsc.com> <7338D97E-0362-486B-AAF1-F9CD64813213@nordsc.com> <4522B945ABF34A74A39FCE1A0C68A9D2@gmail.com> <680DF765108749568E54174961CF84C6@gmail.com> From: mike amundsen Date: Fri, 1 Feb 2013 18:46:49 -0500 X-Google-Sender-Auth: zVI21ryvcJHUSxEGY9O3zNBlbBQ Message-ID: Subject: Re: NEW RELATION: action To: darrel@tavis.ca Content-Type: multipart/alternative; boundary=047d7bfcedb299318504d4b25c1c X-Gm-Message-State: ALoCoQm1aSIVtm2uF+6G609hsooO8YbWRWTRtE2oFHxofpAM90qLu6wszDLo2yQFNGmXGiOJvEo/ Cc: link-relations , 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: Fri, 01 Feb 2013 23:47:44 -0000 --047d7bfcedb299318504d4b25c1c Content-Type: text/plain; charset=ISO-8859-1 Darrel: did you just make a case for the abiltiy to do unsafe non-idempotent empty requests in OData and HAL w/o using this new rel value? mamund +1.859.757.1449 skype: mca.amundsen http://amundsen.com/blog/ http://twitter.com/mamund https://github.com/mamund http://www.linkedin.com/in/mikeamundsen On Fri, Feb 1, 2013 at 6:45 PM, Darrel Miller wrote: > > Mike, > > On Fri, Feb 1, 2013 at 6:13 PM, mike amundsen wrote: > >> >> however, i can describe an "empty POST" in HTML, HAL, Cj, and Siren; >> proly voiceXML, too. Atom doesn't support any variable definitions for >> unsafe transitions (empty or otherwise), but OData's CDSL allows me >> to describe an empty POST. >> >> > > Unless, Mr. Kelly did some magic on HAL while I wasn't looking there is > nothing in the media type that allows you to include hypermedia controls > for unsafe interactions without deferring to a link relation. > > Also, OData has also come to the same conclusion that the concept of an > "action" is necessary, which is why they invented OData "Actions". > http://www.odata.org/blog/2011/10/7/actions-in-odata > > > Darrel > > > > --047d7bfcedb299318504d4b25c1c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Darrel:

did you just make a case for the abiltiy to do u= nsafe non-idempotent empty requests in OData and HAL w/o using this new rel= value?



On Fri, Feb 1, 2013 at 6:45 PM, Darrel M= iller <darrel.miller@gmail.com> wrote:

Mike,

On Fri, Feb 1, = 2013 at 6:13 PM, mike amundsen <mamund@yahoo.com> wrote:

however, i can describe an "empty POST" in HTML, HAL, Cj, an= d Siren; proly voiceXML, too. Atom doesn't support any variable=A0defin= itions for unsafe transitions=A0(empty or otherwise), but OData's CDSL = allows me to=A0describe=A0an empty POST.
=A0

Unless, Mr= . Kelly did some magic on HAL while I wasn't looking there is nothing i= n the media type that allows you to include hypermedia controls for unsafe = interactions without deferring to a link relation.

Also, OData has also come to the same conclusion that t= he concept of an "action" is necessary, which is why they invente= d OData "Actions". =A0http://www.odata.org/blog/2011/10/7= /actions-in-odata


Darrel


=A0

--047d7bfcedb299318504d4b25c1c-- From mca@amundsen.com Fri Feb 1 15:55:03 2013 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 B21E721E8041 for ; Fri, 1 Feb 2013 15:55:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.72 X-Spam-Level: ** X-Spam-Status: No, score=2.72 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FORGED_YAHOO_RCVD=2.297, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_55=0.6, NO_RELAYS=-0.001] 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 0y+vLGxuRK1e for ; Fri, 1 Feb 2013 15:55:02 -0800 (PST) Received: from mail-we0-x231.google.com (we-in-x0231.1e100.net [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0E421F8D1D for ; Fri, 1 Feb 2013 15:55:01 -0800 (PST) Received: by mail-we0-f177.google.com with SMTP id d7so3374186wer.8 for ; Fri, 01 Feb 2013 15:55:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :x-gm-message-state; bh=56aLyXK2smy6HKg9TsvRHz15fHgyD59eJ+hsEQ9xgoI=; b=PE+2De438xEf7cV1XQ5+fxcJnt02Vgx8wnaIrnkrkU9L+6gFiaYlSYpzBevzg04U29 nRwOJIfak2mAwmEy1T7/DKG/hgpYZ0xtRff9zD6BDuhU7bh/XamuqKR/wvm3dtqeAnP4 bJzqnx6VAoGAF9nL4ndDFFK0y4guOGekohv2Qs1/af4sIjoG2rSPm6uTvEoiFjb5SAPe oFS0lqq0qNbz3EPrL+y/3DBcT+/0upWLtoYiS3FV78s/rpUP211edc0DLM/yqmbdyxqY V2nQb3EhzPWqpVb4IxrbV6JAwRLeSUOcvSYIRK8wQ9SK0+lGmVdBdnMaGrrcISispe7G l1BA== X-Received: by 10.180.97.102 with SMTP id dz6mr605319wib.3.1359762900441; Fri, 01 Feb 2013 15:55:00 -0800 (PST) MIME-Version: 1.0 Sender: mca@amundsen.com Received: by 10.194.166.36 with HTTP; Fri, 1 Feb 2013 15:54:40 -0800 (PST) In-Reply-To: References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> <-3128426172162859719@unknownmsgid> <022b01ce0085$a4452b90$eccf82b0$@tavis.ca> <6D2125B5-02DE-4016-86BA-38F8FA100DB4@nordsc.com> <3F268583-BC18-412F-8348-16AFB070EC21@nordsc.com> <694EDD73-FAB5-419E-B72D-717F5F7F21BF@nordsc.com> <7338D97E-0362-486B-AAF1-F9CD64813213@nordsc.com> <4522B945ABF34A74A39FCE1A0C68A9D2@gmail.com> <680DF765108749568E54174961CF84C6@gmail.com> From: mike amundsen Date: Fri, 1 Feb 2013 18:54:40 -0500 X-Google-Sender-Auth: ojGaOFKeUeOYCPqJ6_N0GaOAUqg Message-ID: Subject: Re: NEW RELATION: action To: Ioseb Dzmanashvili Content-Type: multipart/alternative; boundary=f46d043bdde8a8dadb04d4b27855 X-Gm-Message-State: ALoCoQl01Jgm8UFXFRY+tItK7JdKBDDJP9d/3gTWiSoK1QwO7QD6jVjunKo6OjOpQDlDXjfSakw1 Cc: darrel@tavis.ca, link-relations 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, 01 Feb 2013 23:55:03 -0000 --f46d043bdde8a8dadb04d4b27855 Content-Type: text/plain; charset=ISO-8859-1 so, the primary reason for offering this is to be able to describe an unsafe, non-idempotent empty transition using only message metadata (Link header), right? mamund +1.859.757.1449 skype: mca.amundsen http://amundsen.com/blog/ http://twitter.com/mamund https://github.com/mamund http://www.linkedin.com/in/mikeamundsen On Fri, Feb 1, 2013 at 6:44 PM, Ioseb Dzmanashvili < ioseb.dzmanashvili@gmail.com> wrote: > Mike, > > > "simple HTTP messages" is also not quantifiable. I have no doubt you > like this design; might even find it to be "simple" I'm not saying it's > "not simple." maybe you have another thing in mind for "simple" that i'm > not getting here. > > Well, what i mean under "simple" is this: having link relation type like > "action" which has very clear and simple purpose(i.e. send an empty POST > request to this URI), it's very easy to filter out these "action" links > from bunch of other links and present to the application user > contextually(i.e. actions available alongside list items, > window/page/screen level actions etc...) without need to rely on: > > * Application level semantics which are described in underlying media type; > * Application specific conventions; > * Additional documentation; > * Some other assumptions; > * etc... > > As i see it it's mostly useful for applications where users are involved > and less valuable for M2M interactions(though it's possible too). > > Under "simple HTTP messages" i mean that HTTP headers and status codes > could be enough in lots of cases. > > > "single-handedly" is something I can't comment upon since i don't know > what you mean here. > > Sorry for confusion, i meant without involving media types help to > describe such kind of interactions. > > > however, i can describe an "empty POST" in HTML, HAL, Cj, and Siren; > proly voiceXML, too. Atom doesn't support any variable definitions for > unsafe transitions (empty or otherwise), but OData's CDSL allows me to > describe an empty POST. > > I do not argue that it's not possible with mentioned formats, and to be > honest i do it all time. Though there are some cons when using these media > types for describing these unsafe interactions. To be clear, HTML allows us > to construct messages the way we want(i.e. inline empty forms, links, > data...), this format is very well understood by browsers and can be > rendered properly according to its structure. > > On the other hand not HAL nor Cj have such possibilities(i.e rendering). > These formats do not offer such possibility to directly embed multiple > "forms" for constructing empty POST requests. Even it's achievable it > doesn't clearly say how to distinguish such elements from the document. > Whereas links(which both formats support fantastically) could be easily > distinguished and grouped from others by rel values and presented > contextually to users. > > Again, it's not that there is no possibility for doing such things but in > my opinion it's not that simple and clear. > > Best regards, > ioseb > > > On Saturday, February 2, 2013 at 3:13 AM, mike amundsen wrote: > > On Fri, Feb 1, 2013 at 5:45 PM, Ioseb Dzmanashvili < > ioseb.dzmanashvili@gmail.com> wrote: > > Mike, > > > 2 - It's not something I am likely to require in a media type design or > in an instance implementation. And if I did, it would proly be an > application-specific use-case; one that i'd solve within the available > media types themselves. > > The approach i'm trying to defend doesn't require media type(s), message > constructions etc... There are a lot of use cases where such kind of simple > interactions just work and most of the interaction can be carried with > simple HTTP messages + Link header field. This is the point of this link > rel, not that it's impossible to implement such functionality with existing > media types. > > > well "there are lots" is most likely an exercise of availability bias :) I > am telling you here that "It's not something *I* am likely to require..." > not making a statement about your work or anyone else's work. > > "simple HTTP messages" is also not quantifiable. I have no doubt you like > this design; might even find it to be "simple" I'm not saying it's "not > simple." maybe you have another thing in mind for "simple" that i'm not > getting here. > > We agree "it's not impossible... with existing media types" - no problem > there. > > > > 3 - Most all media types i deal w/ allow this already and i don't see an > advantage to create a rel value for it. > > Can you please point me to such media type which allows to implement > similar functionality single-handedly? (i'm really interested). > > "single-handedly" is something I can't comment upon since i don't know > what you mean here. > > however, i can describe an "empty POST" in HTML, HAL, Cj, and Siren; proly > voiceXML, too. Atom doesn't support any variable definitions for unsafe > transitions (empty or otherwise), but OData's CDSL allows me to describe an > empty POST. > > > > > That's my view. > > Thanks! :-) > > Cheers, > ioseb > > On Saturday, February 2, 2013 at 2:17 AM, mike amundsen wrote: > > > 1 - This describes a use-case that is pretty rare in my work (an unsafe, > non-idempotent, empty request for a single protocol). > > 2 - It's not something I am likely to require in a media type design or in > an instance implementation. And if I did, it would proly be an > application-specific use-case; one that i'd solve within the available > media types themselves. > > 3 - Most all media types i deal w/ allow this already and i don't see an > advantage to create a rel value for it. > > 4 - I am not a fan of rel values that define protocol-level actions (e.g. > methods) anyway. > > That's my view. > > mamund > +1.859.757.1449 > skype: mca.amundsen > http://amundsen.com/blog/ > http://twitter.com/mamund > https://github.com/mamund > http://www.linkedin.com/in/mikeamundsen > > > On Fri, Feb 1, 2013 at 5:05 PM, Darrel Miller wrote: > > Mike, > > On Fri, Feb 1, 2013 at 4:51 PM, mike amundsen wrote: > > so, "action" is only for sending an empty HTTP.POST request; nothing > else. no other protocol use (XMPP, WS, FTP, etc.) no HTTP.PUT, PATCH, > DELETE, or any other method that might be added to HTTP in the future, > correct? > > > > If another protocol has an equivalent operation which is unsafe and > requires no parameters, then I see no reason why there cannot be a mapping > for that protocol. However, for HTTP the only other method I can imagine > that might map is DELETE. However, that would then require the > specification of a link-extension parameter to communicate what method to > use. Personally, I would choose to limit it to POST. > > Darrel > > > > > > > --f46d043bdde8a8dadb04d4b27855 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
so, the primary reason for offering this is to be able to describe an = unsafe, non-idempotent empty transition using only message metadata (Link h= eader), right?

mamund


On Fri, Feb 1, 2013 at 6:44 PM, Ioseb Dz= manashvili <ioseb.dzmanashvili@gmail.com> wrote:<= br>
Mike,

= > "simple HTTP messages" is also not quantifiable. I have no d= oubt you like this design; might even find it to be "simple" I= 9;m not saying it's "not simple." maybe you have another thin= g in mind for "simple" that i'm not getting here.

Well, what i mean under "simple" is thi= s: having link relation type like "action" which has very clear a= nd simple purpose(i.e. send an empty POST request to this URI), it's ve= ry easy to filter out these "action" links from bunch of other li= nks and present to the application user contextually(i.e. actions available= alongside list items, window/page/screen level actions etc...) without nee= d to rely on:

* Application level semantics which are described in un= derlying media type;
* Application specific conventions;
* Additional documentation;
* Some other assumptions;
* etc...

As i see it it's mostly useful f= or applications where users are involved and less valuable for M2M interact= ions(though it's possible too).

Under "si= mple HTTP messages" i mean that HTTP headers and status codes could be= enough in lots of cases.

> "single-handedly" is s= omething I can't comment upon since i don't know what you mean here= .

Sorry for confusion, i meant without invol= ving media types help to describe such kind of interactions.

> however, i can describe an "= ;empty POST" in HTML, HAL, Cj, and Siren; proly voiceXML, too. Atom do= esn't support any variable definitions for unsafe transitions (empty or= otherwise), but OData's CDSL allows me to describe an empty POST.

I do not argue that it's not possible with me= ntioned formats, and to be honest i do it all time. Though there are some c= ons when using these media types for describing these unsafe interactions. = To be clear, HTML allows us to construct messages the way we want(i.e. inli= ne empty forms, links, data...), this format is very well understood by bro= wsers and can be rendered properly according to its structure.=A0

On the other hand not HAL nor Cj have such possibilitie= s(i.e rendering). These formats do not offer such possibility to directly e= mbed multiple "forms" for constructing empty POST requests. Even = it's achievable it doesn't clearly say how to distinguish such elem= ents from the document. Whereas links(which both formats support fantastica= lly) could be easily distinguished and grouped from others by rel values an= d presented contextually to users.

Again, it's not that there is no possibility for do= ing such things but in my opinion it's not that simple and clear.
=

Best regards,
ioseb


=20

On Saturday, February 2, 2013 at= 3:13 AM, mike amundsen wrote:

On Fri, Feb 1, 2013 at 5:45 PM, Ioseb D= zmanashvili <ioseb.dzmanashvili@gmail.com> wrote:=
Mike,

> 2 - It&#= 39;s not something I am likely to require in a media type design or in an i= nstance implementation. And if I did, it would proly be an application-spec= ific use-case; one that i'd solve within the available media types them= selves.=A0

The approach i'm trying to defend doesn't= require media type(s), message constructions etc... There are a lot of use= cases where such kind of simple interactions just work and most of the int= eraction can be carried with simple HTTP messages + Link header field. This= is the point of this link rel, not that it's impossible to implement s= uch functionality with existing media types.

well "there are lots"= ; is most likely an exercise of availability bias :) I am telling you here = that "It's not something *I* am likely to require..." not mak= ing a statement about your work or anyone else's work.

"simple HTTP messages" is also not quantifiab= le. I have no doubt you like this design; might even find it to be "si= mple" I'm not saying it's "not simple." maybe you ha= ve another thing in mind for "simple" that i'm not getting he= re.

We agree "it's not impossible... with existing= media types" - no problem there.


> 3 - Most all media types i deal w/ allow= this already and i don't see an advantage to create a rel value for it= .

Can you please point me to such media type= which allows to implement similar functionality single-handedly? (i'm = really interested).
"single-handedly" is something I ca= n't comment upon since i don't know what you mean here.=A0

however, i can describe an "empty POST" in HTML,= HAL, Cj, and Siren; proly voiceXML, too. Atom doesn't support any vari= able=A0definitions for unsafe transitions=A0(empty or otherwise), but OData= 's CDSL allows me to=A0describe=A0an empty POST.
=A0

> That's my view.

Thanks! :-)

Cheers,
ioseb
=20

On Saturday, February 2, 2013 at= 2:17 AM, mike amundsen wrote:


1 - This describes a use= -case that is pretty rare in my work (an unsafe, non-idempotent, empty requ= est for a single protocol).

2 - It's not something I= am likely to require in a media type design or in an instance implementati= on. And if I did, it would proly be an application-specific use-case; one t= hat i'd solve within the available media types themselves.=A0

3 - Most all media types i deal w/ allow this already a= nd i don't see an advantage to create a rel value for it.
4 - I am not a fan of rel values that define protocol-level act= ions (e.g. methods) anyway.

That's my view.



On Fri, Feb 1, 2013 at 5:05 PM, Darrel Miller <darrel.m= iller@gmail.com> wrote:
Mike,

On Fri, Feb 1, 2013 at 4:51 P= M, mike amundsen <mamund@yahoo.com> wrote:
so, "action" is only for sending an empty HTTP.POST request;= nothing else. no other protocol use (XMPP, WS, FTP, etc.) no HTTP.PUT, PAT= CH, DELETE, or any other method that might be added to HTTP in the future, = correct?


If another= protocol has an equivalent operation which is unsafe and requires no param= eters, then =A0I see no reason why there cannot be a mapping for that proto= col. =A0However, for HTTP the only other method I can imagine that might ma= p is DELETE. =A0However, that would then require the specification of a lin= k-extension parameter to communicate what method to use. =A0Personally, I w= ould choose to limit it to POST.

Darrel=A0
=A0
=

=20 =20 =20 =20


=20 =20 =20 =20
=20


--f46d043bdde8a8dadb04d4b27855-- From ioseb.dzmanashvili@gmail.com Fri Feb 1 15:58:31 2013 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 6FFAB21E8089 for ; Fri, 1 Feb 2013 15:58:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.460, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_38=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 5aLFMpVzZHrk for ; Fri, 1 Feb 2013 15:58:30 -0800 (PST) Received: from mail-ea0-f170.google.com (mail-ea0-f170.google.com [209.85.215.170]) by ietfa.amsl.com (Postfix) with ESMTP id 2372F21E8041 for ; Fri, 1 Feb 2013 15:58:29 -0800 (PST) Received: by mail-ea0-f170.google.com with SMTP id a11so1942617eaa.15 for ; Fri, 01 Feb 2013 15:58:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:message-id:in-reply-to:references :subject:x-mailer:mime-version:content-type; bh=fYJo7uCWYYxJK9yrqC9wcpHGzG9Lyakgvaab25Pzr+U=; b=nOsiBXUY7BYBpUW/y/pp+jEKUjhF62Wa/Jm34cjhihfrZr5NxxDa2Q4I8y7wRVTdgr hmgW/ukkvtHGvmfC4MLA34b9vOnSA7KD3QorQek/asPnYLupf2GxzsEYkV/NHvgCk4Eg 6s+qz0OA0JOvWyiT7UsaJnzyXWdLmNUdIJi+JqT4xUX1wA7MQf7MPE43iJVF6EZR2ZUI Nb6TpFXu72ZnAQTi+J+OOQksNR1jsAFXghQvlb6bmdDEvCeUXz14xT1X/IgSgZdYYli0 TRLevzPBFf5E1BJ1dA4TQuj4Qp3Kj2qBhYFFxERMdB8P1HR1YHQ0a4johbnpJoPBWZ8k Dcow== X-Received: by 10.14.173.69 with SMTP id u45mr44686747eel.21.1359763109284; Fri, 01 Feb 2013 15:58:29 -0800 (PST) Received: from [192.168.1.3] ([176.73.174.236]) by mx.google.com with ESMTPS id h5sm14976910eem.1.2013.02.01.15.58.26 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 01 Feb 2013 15:58:28 -0800 (PST) Date: Sat, 2 Feb 2013 03:58:27 +0400 From: Ioseb Dzmanashvili To: mike amundsen Message-ID: <7EBC6976FB50437AA1BCA0079854D359@gmail.com> In-Reply-To: References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> <-3128426172162859719@unknownmsgid> <022b01ce0085$a4452b90$eccf82b0$@tavis.ca> <6D2125B5-02DE-4016-86BA-38F8FA100DB4@nordsc.com> <3F268583-BC18-412F-8348-16AFB070EC21@nordsc.com> <694EDD73-FAB5-419E-B72D-717F5F7F21BF@nordsc.com> <7338D97E-0362-486B-AAF1-F9CD64813213@nordsc.com> <4522B945ABF34A74A39FCE1A0C68A9D2@gmail.com> <680DF765108749568E54174961CF84C6@gmail.com> Subject: Re: NEW RELATION: action X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="510c56a3_6552335_28a" Cc: darrel@tavis.ca, link-relations 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, 01 Feb 2013 23:58:31 -0000 --510c56a3_6552335_28a Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Mike, Let me ask question before Darrel responds. > Darrel: > did you just make a case for the abiltiy to do unsafe non-idempotent empty requests in OData and HAL w/o using this new rel value? How this thing: is different from: Link: ; rel="action http://otherserver/$metadata#MyEntities.Checkout"; title="Checkout Donnie Darko" Other than it's a part of the media type itself and is not directly useful outside the OData format? Also, how it's possible to implement this in HAL without introducing some additional structure(extending the format or introducing some specific convention on particular application implementation level) Cheers, ioseb On Saturday, February 2, 2013 at 3:46 AM, mike amundsen wrote: > Darrel: > > did you just make a case for the abiltiy to do unsafe non-idempotent empty requests in OData and HAL w/o using this new rel value? > > mamund > +1.859.757.1449 > skype: mca.amundsen > http://amundsen.com/blog/ > http://twitter.com/mamund > https://github.com/mamund > http://www.linkedin.com/in/mikeamundsen > > On Fri, Feb 1, 2013 at 6:45 PM, Darrel Miller wrote: > > > > Mike, > > > > On Fri, Feb 1, 2013 at 6:13 PM, mike amundsen wrote: > > > > > > however, i can describe an "empty POST" in HTML, HAL, Cj, and Siren; proly voiceXML, too. Atom doesn't support any variable definitions for unsafe transitions (empty or otherwise), but OData's CDSL allows me to describe an empty POST. > > > > > > > > > > > > > > > > > > Unless, Mr. Kelly did some magic on HAL while I wasn't looking there is nothing in the media type that allows you to include hypermedia controls for unsafe interactions without deferring to a link relation. > > > > Also, OData has also come to the same conclusion that the concept of an "action" is necessary, which is why they invented OData "Actions". http://www.odata.org/blog/2011/10/7/actions-in-odata > > > > > > Darrel > > > > > > --510c56a3_6552335_28a Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Mike,

Let me ask question b= efore Darrel responds.

> Darrel:
&g= t; did you just make a case for the abiltiy to do unsafe non-idempotent e= mpty requests in OData and HAL w/o using this new rel value=3F
=
How this thing:

<m:action rel=3D= =22http://otherserver/=24metadata=23MyEntities.Checkout=22 
          target=3D=22Movies(6)/Checkout=22&nb= sp;
          title=3D=22Checkout Donn= ie Darko=22 />

is different from: Link: <M= ovies(6)/Checkout>; rel=3D=22action http://otherserver/=24metadata=23M= yEntities.Checkout=22; title=3D=22Checkout Donnie Darko=22

=
Other than it's a part of the media type itself and is not dir= ectly useful outside the OData format=3F

Also, h= ow it's possible to implement this in HAL without introducing some additi= onal structure(extending the format or introducing some specific conventi= on on particular application implementation level)

Cheers,
ioseb

On Saturday, =46ebruary 2, 2013 at 3:46 AM, mike amundsen wrote:=
Darrel:

did you ju= st make a case for the abiltiy to do unsafe non-idempotent empty requests= in OData and HAL w/o using this new rel value=3F



On =46ri, =46eb 1, 2013 at 6:45 PM, Darrel Miller <darrel.miller=40gmail.com> wrote:

Mike,

On =46ri, =46= eb 1, 2013 at 6:13 PM, mike amundsen <mamund=40yahoo.co= m> wrote:

however, i can describe an =22empty POST=22 in HTML, HAL, Cj, and Si= ren; proly voiceXML, too. Atom doesn't support any variable definiti= ons for unsafe transitions (empty or otherwise), but OData's CDSL al= lows me to describe an empty POST.
 

Unless, Mr. Kelly did some magic on HAL while I wasn't looking there is = nothing in the media type that allows you to include hypermedia controls = for unsafe interactions without deferring to a link relation.

Also, OData has also come to the same conclusion that= the concept of an =22action=22 is necessary, which is why they invented = OData =22Actions=22.  http://www.odata.org/blog/= 2011/10/7/actions-in-odata


Darrel


 

=20 =20 =20 =20 =20

--510c56a3_6552335_28a-- From ioseb.dzmanashvili@gmail.com Fri Feb 1 16:01:57 2013 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 DE33421E804A for ; Fri, 1 Feb 2013 16:01:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[AWL=-0.482, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_55=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 LKhaROOXEgSO for ; Fri, 1 Feb 2013 16:01:56 -0800 (PST) Received: from mail-ee0-f53.google.com (mail-ee0-f53.google.com [74.125.83.53]) by ietfa.amsl.com (Postfix) with ESMTP id D4C8F21E8041 for ; Fri, 1 Feb 2013 16:01:55 -0800 (PST) Received: by mail-ee0-f53.google.com with SMTP id e53so2286325eek.26 for ; Fri, 01 Feb 2013 16:01:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:message-id:in-reply-to:references :subject:x-mailer:mime-version:content-type; bh=iQ7CS/qC3qQCU/TWy+tfTL4MEeOte6fTBDYc6b4tv6Y=; b=eb0M0l1JU1ERUsT9/li9zYiAkzkwFYjDIr8AK91ZR/LoPqixkh1xAYdAv1YJEZLpCP HA0c/Yr7FqTH6pjkCAv8o5XvFg/JjV8T+St78HRgTnDc9Ncj2xUVwr+MMEWMGLqvemdZ 4YrdQvrFyxQkvN7C3RPEqpkx5oudUauGZfc1f06UvpwjX5ieUyAPZwGJczcM8DhJPMjd wREoOu2BtFmh4izvPt1veQRMmGpnPX+QMCXhZMk4ZKkOzwfYWWrW8r+4rpg9JaOCYEMj ahAkACYaQUZyoGpfMkT6LUWNDAytwu8eWNH+sLP27ao1EpIJGxj/BxkuExmHK7OcLp4Y uWbg== X-Received: by 10.14.175.70 with SMTP id y46mr44505783eel.6.1359763314863; Fri, 01 Feb 2013 16:01:54 -0800 (PST) Received: from [192.168.1.3] ([176.73.174.236]) by mx.google.com with ESMTPS id 43sm14964851eed.10.2013.02.01.16.01.51 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 01 Feb 2013 16:01:52 -0800 (PST) Date: Sat, 2 Feb 2013 04:01:51 +0400 From: Ioseb Dzmanashvili To: mike amundsen Message-ID: In-Reply-To: References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> <-3128426172162859719@unknownmsgid> <022b01ce0085$a4452b90$eccf82b0$@tavis.ca> <6D2125B5-02DE-4016-86BA-38F8FA100DB4@nordsc.com> <3F268583-BC18-412F-8348-16AFB070EC21@nordsc.com> <694EDD73-FAB5-419E-B72D-717F5F7F21BF@nordsc.com> <7338D97E-0362-486B-AAF1-F9CD64813213@nordsc.com> <4522B945ABF34A74A39FCE1A0C68A9D2@gmail.com> <680DF765108749568E54174961CF84C6@gmail.com> Subject: Re: NEW RELATION: action X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="510c576f_335d34ea_28a" Cc: darrel@tavis.ca, link-relations 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: Sat, 02 Feb 2013 00:01:58 -0000 --510c576f_335d34ea_28a Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Mike, > so, the primary reason for offering this is to be able to describe an unsafe, non-idempotent empty transition using only message metadata (Link header), right? No of course, it can be used in other formats too i believe. ioseb On Saturday, February 2, 2013 at 3:54 AM, mike amundsen wrote: > so, the primary reason for offering this is to be able to describe an unsafe, non-idempotent empty transition using only message metadata (Link header), right? > > mamund > +1.859.757.1449 > skype: mca.amundsen > http://amundsen.com/blog/ > http://twitter.com/mamund > https://github.com/mamund > http://www.linkedin.com/in/mikeamundsen > > On Fri, Feb 1, 2013 at 6:44 PM, Ioseb Dzmanashvili wrote: > > Mike, > > > > > "simple HTTP messages" is also not quantifiable. I have no doubt you like this design; might even find it to be "simple" I'm not saying it's "not simple." maybe you have another thing in mind for "simple" that i'm not getting here. > > > > Well, what i mean under "simple" is this: having link relation type like "action" which has very clear and simple purpose(i.e. send an empty POST request to this URI), it's very easy to filter out these "action" links from bunch of other links and present to the application user contextually(i.e. actions available alongside list items, window/page/screen level actions etc...) without need to rely on: > > > > * Application level semantics which are described in underlying media type; > > * Application specific conventions; > > * Additional documentation; > > * Some other assumptions; > > * etc... > > > > As i see it it's mostly useful for applications where users are involved and less valuable for M2M interactions(though it's possible too). > > > > Under "simple HTTP messages" i mean that HTTP headers and status codes could be enough in lots of cases. > > > > > "single-handedly" is something I can't comment upon since i don't know what you mean here. > > > > Sorry for confusion, i meant without involving media types help to describe such kind of interactions. > > > > > however, i can describe an "empty POST" in HTML, HAL, Cj, and Siren; proly voiceXML, too. Atom doesn't support any variable definitions for unsafe transitions (empty or otherwise), but OData's CDSL allows me to describe an empty POST. > > > > I do not argue that it's not possible with mentioned formats, and to be honest i do it all time. Though there are some cons when using these media types for describing these unsafe interactions. To be clear, HTML allows us to construct messages the way we want(i.e. inline empty forms, links, data...), this format is very well understood by browsers and can be rendered properly according to its structure. > > > > On the other hand not HAL nor Cj have such possibilities(i.e rendering). These formats do not offer such possibility to directly embed multiple "forms" for constructing empty POST requests. Even it's achievable it doesn't clearly say how to distinguish such elements from the document. Whereas links(which both formats support fantastically) could be easily distinguished and grouped from others by rel values and presented contextually to users. > > > > Again, it's not that there is no possibility for doing such things but in my opinion it's not that simple and clear. > > > > Best regards, > > ioseb > > > > > > > > On Saturday, February 2, 2013 at 3:13 AM, mike amundsen wrote: > > > > > > > On Fri, Feb 1, 2013 at 5:45 PM, Ioseb Dzmanashvili wrote: > > > > Mike, > > > > > > > > > 2 - It's not something I am likely to require in a media type design or in an instance implementation. And if I did, it would proly be an application-specific use-case; one that i'd solve within the available media types themselves. > > > > > > > > The approach i'm trying to defend doesn't require media type(s), message constructions etc... There are a lot of use cases where such kind of simple interactions just work and most of the interaction can be carried with simple HTTP messages + Link header field. This is the point of this link rel, not that it's impossible to implement such functionality with existing media types. > > > > > > well "there are lots" is most likely an exercise of availability bias :) I am telling you here that "It's not something *I* am likely to require..." not making a statement about your work or anyone else's work. > > > > > > "simple HTTP messages" is also not quantifiable. I have no doubt you like this design; might even find it to be "simple" I'm not saying it's "not simple." maybe you have another thing in mind for "simple" that i'm not getting here. > > > > > > We agree "it's not impossible... with existing media types" - no problem there. > > > > > > > > > > > > 3 - Most all media types i deal w/ allow this already and i don't see an advantage to create a rel value for it. > > > > > > > > Can you please point me to such media type which allows to implement similar functionality single-handedly? (i'm really interested). > > > "single-handedly" is something I can't comment upon since i don't know what you mean here. > > > > > > however, i can describe an "empty POST" in HTML, HAL, Cj, and Siren; proly voiceXML, too. Atom doesn't support any variable definitions for unsafe transitions (empty or otherwise), but OData's CDSL allows me to describe an empty POST. > > > > > > > > > > > > That's my view. > > > > > > > > Thanks! :-) > > > > > > > > Cheers, > > > > ioseb > > > > > > > > > > > > On Saturday, February 2, 2013 at 2:17 AM, mike amundsen wrote: > > > > > > > > > > > > > > 1 - This describes a use-case that is pretty rare in my work (an unsafe, non-idempotent, empty request for a single protocol). > > > > > > > > > > 2 - It's not something I am likely to require in a media type design or in an instance implementation. And if I did, it would proly be an application-specific use-case; one that i'd solve within the available media types themselves. > > > > > > > > > > 3 - Most all media types i deal w/ allow this already and i don't see an advantage to create a rel value for it. > > > > > > > > > > 4 - I am not a fan of rel values that define protocol-level actions (e.g. methods) anyway. > > > > > > > > > > That's my view. > > > > > > > > > > mamund > > > > > +1.859.757.1449 (tel:%2B1.859.757.1449) > > > > > skype: mca.amundsen > > > > > http://amundsen.com/blog/ > > > > > http://twitter.com/mamund > > > > > https://github.com/mamund > > > > > http://www.linkedin.com/in/mikeamundsen > > > > > > > > > > On Fri, Feb 1, 2013 at 5:05 PM, Darrel Miller wrote: > > > > > > Mike, > > > > > > > > > > > > On Fri, Feb 1, 2013 at 4:51 PM, mike amundsen wrote: > > > > > > > so, "action" is only for sending an empty HTTP.POST request; nothing else. no other protocol use (XMPP, WS, FTP, etc.) no HTTP.PUT, PATCH, DELETE, or any other method that might be added to HTTP in the future, correct? > > > > > > > > > > > > > > > > > > > If another protocol has an equivalent operation which is unsafe and requires no parameters, then I see no reason why there cannot be a mapping for that protocol. However, for HTTP the only other method I can imagine that might map is DELETE. However, that would then require the specification of a link-extension parameter to communicate what method to use. Personally, I would choose to limit it to POST. > > > > > > > > > > > > Darrel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --510c576f_335d34ea_28a Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Mike,

> so, the pri= mary reason for offering this is to be able to describe an unsafe, non-id= empotent empty transition using only message metadata (Link header), righ= t=3F

No of course, it can be used in other forma= ts too i believe. 

ioseb
=20

On Saturday, =46ebruar= y 2, 2013 at 3:54 AM, mike amundsen wrote:

so, the primary reason for offer= ing this is to be able to describe an unsafe, non-idempotent empty transi= tion using only message metadata (Link header), right=3F

mamund


On =46ri, =46eb 1, 2013 at 6:44 PM, Ioseb Dzmanashvili <ioseb.dzmanashvili=40gmail.com> wr= ote:
Mike,

> =22sim= ple HTTP messages=22 is also not quantifiable. I have no doubt you like t= his design; might even find it to be =22simple=22 I'm not saying it's =22= not simple.=22 maybe you have another thing in mind for =22simple=22 that= i'm not getting here.

Well, what i mean under =22simple=22 is this: h= aving link relation type like =22action=22 which has very clear and simpl= e purpose(i.e. send an empty POST request to this URI), it's very easy to= filter out these =22action=22 links from bunch of other links and presen= t to the application user contextually(i.e. actions available alongside l= ist items, window/page/screen level actions etc...) without need to rely = on:

* Application level semantics which are described in = underlying media type;
* Application specific conventions;
* Additional documentation;
* Some other assumptions;
* etc...

As i see it it's mostly useful for= applications where users are involved and less valuable for M2M interact= ions(though it's possible too).

Under =22simple = HTTP messages=22 i mean that HTTP headers and status codes could be enoug= h in lots of cases.

> =22single-handedly=22 is something I can't = comment upon since i don't know what you mean here.

<= /div>
Sorry for confusion, i meant without involving media types help= to describe such kind of interactions.

> however, i can describe an =22empty POST=22= in HTML, HAL, Cj, and Siren; proly voiceXML, too. Atom doesn't support a= ny variable definitions for unsafe transitions (empty or otherwise), but = OData's CDSL allows me to describe an empty POST.

I do not argue that it's not possible with ment= ioned formats, and to be honest i do it all time. Though there are some c= ons when using these media types for describing these unsafe interactions= . To be clear, HTML allows us to construct messages the way we want(i.e. = inline empty forms, links, data...), this format is very well understood = by browsers and can be rendered properly according to its structure. = ;

On the other hand not HAL nor Cj have such possibilit= ies(i.e rendering). These formats do not offer such possibility to direct= ly embed multiple =22forms=22 for constructing empty POST requests. Even = it's achievable it doesn't clearly say how to distinguish such elements f= rom the document. Whereas links(which both formats support fantastically)= could be easily distinguished and grouped from others by rel values and = presented contextually to users.

Again, it's not that there is no possibility for doin= g such things but in my opinion it's not that simple and clear.

Best regards,
ioseb


=20

On Saturday, =46ebruary = 2, 2013 at 3:13 AM, mike amundsen wrote:

On =46ri, =46eb 1, 2013 at 5:45 PM, I= oseb Dzmanashvili <ioseb.dzmanashvili=40gma= il.com> wrote:
Mike,

> 2 - It= 's not something I am likely to require in a media type design or in an i= nstance implementation. And if I did, it would proly be an application-sp= ecific use-case; one that i'd solve within the available media types them= selves. 

The approach i'm trying to defend doesn't requi= re media type(s), message constructions etc... There are a lot of use cas= es where such kind of simple interactions just work and most of the inter= action can be carried with simple HTTP messages + Link header field. This= is the point of this link rel, not that it's impossible to implement suc= h functionality with existing media types.

well =22there are lots=22 is= most likely an exercise of availability bias :) I am telling you here th= at =22It's not something *I* am likely to require...=22 not making a stat= ement about your work or anyone else's work.

=22simple HTTP messages=22 is also not quantifiable. = I have no doubt you like this design; might even find it to be =22simple=22= I'm not saying it's =22not simple.=22 maybe you have another thing in mi= nd for =22simple=22 that i'm not getting here.

We agree =22it's not impossible... with existing medi= a types=22 - no problem there.


> 3 - Most all media types i deal w/ all= ow this already and i don't see an advantage to create a rel value for it= .

Can you please point me to such media ty= pe which allows to implement similar functionality single-handedly=3F (i'= m really interested).
=22single-handedly=22 is something I can't = comment upon since i don't know what you mean here. 

<= /div>
however, i can describe an =22empty POST=22 in HTML, HAL, Cj, a= nd Siren; proly voiceXML, too. Atom doesn't support any variable def= initions for unsafe transitions (empty or otherwise), but OData's CD= SL allows me to describe an empty POST.
 

> That's my= view.

Thanks=21 :-)
<= br>
Cheers,
ioseb
=20

On Saturday, =46ebruary = 2, 2013 at 2:17 AM, mike amundsen wrote:


1 - This describes a u= se-case that is pretty rare in my work (an unsafe, non-idempotent, empty = request for a single protocol).

2 - It's not something= I am likely to require in a media type design or in an instance implemen= tation. And if I did, it would proly be an application-specific use-case;= one that i'd solve within the available media types themselves. 

3 - Most all media types i deal w/ allow this already= and i don't see an advantage to create a rel value for it.
4 - I am not a fan of rel values that define protocol-level a= ctions (e.g. methods) anyway.

That's my view.



On =46ri, =46eb 1, 2013 at 5:05 PM, Darrel Miller <darrel.miller=40gmail.com> wrote:
Mike,

On =46ri, =46eb 1, 2013= at 4:51 PM, mike amundsen <mamund=40yahoo.com><= /span> wrote:
so, =22action=22 is only for sending an empty HTTP.POST request; not= hing else. no other protocol use (XMPP, WS, =46TP, etc.) no HTTP.PUT, PAT= CH, DELETE, or any other method that might be added to HTTP in the future= , correct=3F

<= div>If another protocol has an equivalent operation which is unsafe and r= equires no parameters, then  I see no reason why there cannot be a m= apping for that protocol.  However, for HTTP the only other method I= can imagine that might map is DELETE.  However, that would then req= uire the specification of a link-extension parameter to communicate what = method to use.  Personally, I would choose to limit it to POST.

Darrel 
 

=20 =20 =20 =20


=20 =20 =20 =20


=20 =20 =20 =20 =20

--510c576f_335d34ea_28a-- From mca@amundsen.com Fri Feb 1 16:06:03 2013 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 67E2B21E804A for ; Fri, 1 Feb 2013 16:06:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.521 X-Spam-Level: X-Spam-Status: No, score=0.521 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FORGED_YAHOO_RCVD=2.297, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, J_CHICKENPOX_64=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 FFuYaVC-d5+B for ; Fri, 1 Feb 2013 16:06:02 -0800 (PST) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by ietfa.amsl.com (Postfix) with ESMTP id 1B06E21E8041 for ; Fri, 1 Feb 2013 16:06:01 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id 15so3235798wgd.28 for ; Fri, 01 Feb 2013 16:06:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :x-gm-message-state; bh=p4HqaAj3s4Nlt81QDBosxnaWfFxdC661mn9EfXa2e8A=; b=eopAp4V39/f8O4/Lf0HXrMUWJP6427fB7H35QyvfusT22eQmWWRPWjTOYicTy1FMSm KVobd/0vBviusQXdUIh0Pnr+RuPgrJZvK5tEAScGZZ5wGzGo/hupsGUsw1OlsimeyqvD 6dqPCpSlTP6qwVHs/1xTCtpGuKiFlstBvpIPtMWmpVVo8U3BBoVniT46WCHeNy2VnKSq fOuKWOPfFnrK3x+fOBn/mgu1T3kIko61qMqPx/3ocTG3EFUnG/4AupMzmbFRN5VtPsRo YJA1o76TNYawBqBpZo1Wvv+XQaOrgr0tO3d1JdxU6d+08gr0XTfU3qFCh/LNi8pTv2oC vI4Q== X-Received: by 10.180.84.162 with SMTP id a2mr585097wiz.14.1359763561240; Fri, 01 Feb 2013 16:06:01 -0800 (PST) MIME-Version: 1.0 Sender: mca@amundsen.com Received: by 10.194.166.36 with HTTP; Fri, 1 Feb 2013 16:05:41 -0800 (PST) In-Reply-To: <7EBC6976FB50437AA1BCA0079854D359@gmail.com> References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> <-3128426172162859719@unknownmsgid> <022b01ce0085$a4452b90$eccf82b0$@tavis.ca> <6D2125B5-02DE-4016-86BA-38F8FA100DB4@nordsc.com> <3F268583-BC18-412F-8348-16AFB070EC21@nordsc.com> <694EDD73-FAB5-419E-B72D-717F5F7F21BF@nordsc.com> <7338D97E-0362-486B-AAF1-F9CD64813213@nordsc.com> <4522B945ABF34A74A39FCE1A0C68A9D2@gmail.com> <680DF765108749568E54174961CF84C6@gmail.com> <7EBC6976FB50437AA1BCA0079854D359@gmail.com> From: mike amundsen Date: Fri, 1 Feb 2013 19:05:41 -0500 X-Google-Sender-Auth: L3vdE_fA2FWo2VSEyW6aX0_5X_8 Message-ID: Subject: Re: NEW RELATION: action To: Ioseb Dzmanashvili Content-Type: multipart/alternative; boundary=f46d044271940bda4f04d4b2a093 X-Gm-Message-State: ALoCoQkYMT55qp0qpLKqrVmrwOIjSwXQa8h2d1MTqZSnmLG4CIZKWknIk8/CuvoxgSkZ06Y2QVqX Cc: darrel@tavis.ca, link-relations 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: Sat, 02 Feb 2013 00:06:03 -0000 --f46d044271940bda4f04d4b2a093 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Feb 1, 2013 at 6:58 PM, Ioseb Dzmanashvili < ioseb.dzmanashvili@gmail.com> wrote: > Mike, > > Let me ask question before Darrel responds. > > > Darrel: > > did you just make a case for the abiltiy to do unsafe non-idempotent > empty requests in OData and HAL w/o using this new rel value? > > How this thing: > > target="Movies(6)/Checkout" > title="Checkout Donnie Darko" /> > > is different from: Link: ; rel="action > http://otherserver/$metadata#MyEntities.Checkout"; title="Checkout Donnie > Darko" > > Other than it's a part of the media type itself and is not directly useful > outside the OData format? > Since one of your key cases is that your proposal bypasses describing the transition within a message body, I suppose the only difference is the one you think is important, right? > > Also, how it's possible to implement this in HAL without introducing some > additional structure(extending the format or introducing some specific > convention on particular application implementation level) > In my (limited) use of HAL, all transition semantics (methods, bodies, etc.) are supplied in human readable documentation and associated w/ a rel value. I just write documentation that sez pass no arguments in the body, method=POST and associate that w/ my selected link rel value. > Cheers, > ioseb > > On Saturday, February 2, 2013 at 3:46 AM, mike amundsen wrote: > > Darrel: > > did you just make a case for the abiltiy to do unsafe non-idempotent empty > requests in OData and HAL w/o using this new rel value? > > mamund > +1.859.757.1449 > skype: mca.amundsen > http://amundsen.com/blog/ > http://twitter.com/mamund > https://github.com/mamund > http://www.linkedin.com/in/mikeamundsen > > > On Fri, Feb 1, 2013 at 6:45 PM, Darrel Miller wrote: > > > Mike, > > On Fri, Feb 1, 2013 at 6:13 PM, mike amundsen wrote: > > > however, i can describe an "empty POST" in HTML, HAL, Cj, and Siren; proly > voiceXML, too. Atom doesn't support any variable definitions for unsafe > transitions (empty or otherwise), but OData's CDSL allows me to describe an > empty POST. > > > > Unless, Mr. Kelly did some magic on HAL while I wasn't looking there is > nothing in the media type that allows you to include hypermedia controls > for unsafe interactions without deferring to a link relation. > > Also, OData has also come to the same conclusion that the concept of an > "action" is necessary, which is why they invented OData "Actions". > http://www.odata.org/blog/2011/10/7/actions-in-odata > > > Darrel > > > > > > > --f46d044271940bda4f04d4b2a093 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Feb 1, 2013 at 6:58 PM, Ioseb Dzmanashvili <ioseb.dzman= ashvili@gmail.com> wrote:
Mike,

Let me ask question bef= ore Darrel responds.

> Darrel= :
> did you just make a case for the abiltiy to do unsafe non-= idempotent empty requests in OData and HAL w/o using this new rel value?

How this thing:

=A0 =A0 =A0 =A0 =A0 target=3D"Movies(6)/Checkout"=A0
=A0 =A0 =A0 =A0 =A0 title=3D"Checkout Donnie Darko" />

is different from: Link: <Movies(6)/Checkout>; r= el=3D"action http://otherserver/$metadata#MyEntities.Checkout&= quot;; title=3D"Checkout Donnie Darko"

Other than = it's a part of the media type itself and is not directly useful outside= the OData format?
=A0
Since one of your key cases is that your pr= oposal bypasses describing the transition within a message body, I suppose = the only difference is the one you think is important, right?
=A0

Also, how it's possi= ble to implement this in HAL without introducing some additional structure(= extending the format or introducing some specific convention on particular = application implementation level)
=A0
In my (limited) use of HAL, all transition = semantics (methods, bodies, etc.) are supplied in human readable documentat= ion and associated w/ a rel value. I just write documentation that sez pass= no arguments in the body, method=3DPOST and associate that w/ my selected = link rel value.=A0


Cheers,
ioseb

On Saturday, Febru= ary 2, 2013 at 3:46 AM, mike amundsen wrote:
Darrel:

did you just= make a case for the abiltiy to do unsafe non-idempotent empty requests in = OData and HAL w/o using this new rel value?



On Fri, Feb 1, 2013 at 6:45 PM, Darrel Miller <darrel.m= iller@gmail.com> wrote:

Mike,

On Fri, Feb 1, 2013= at 6:13 PM, mike amundsen <mamund@yahoo.com> wrote:

however, i can describe an "empty POST" in HTML, HAL, Cj, an= d Siren; proly voiceXML, too. Atom doesn't support any variable=A0defin= itions for unsafe transitions=A0(empty or otherwise), but OData's CDSL = allows me to=A0describe=A0an empty POST.
=A0

Unle= ss, Mr. Kelly did some magic on HAL while I wasn't looking there is not= hing in the media type that allows you to include hypermedia controls for u= nsafe interactions without deferring to a link relation.

Also, OData has also come to the same conclusion that t= he concept of an "action" is necessary, which is why they invente= d OData "Actions". =A0http://www.odata.org/blog/2011/10/7= /actions-in-odata


Darrel


=A0

 =20 =20 =20 =20
=20


--f46d044271940bda4f04d4b2a093-- From mca@amundsen.com Fri Feb 1 16:06:34 2013 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 C972B21E804A for ; Fri, 1 Feb 2013 16:06:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.72 X-Spam-Level: ** X-Spam-Status: No, score=2.72 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FORGED_YAHOO_RCVD=2.297, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_55=0.6, NO_RELAYS=-0.001] 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 EylPL7TW3p43 for ; Fri, 1 Feb 2013 16:06:33 -0800 (PST) Received: from mail-we0-x230.google.com (we-in-x0230.1e100.net [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id DD9C021E8041 for ; Fri, 1 Feb 2013 16:06:32 -0800 (PST) Received: by mail-we0-f176.google.com with SMTP id s43so3291312wey.21 for ; Fri, 01 Feb 2013 16:06:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :x-gm-message-state; bh=c1AlO/cMA+6nJpekdGsM5siPLIk+QO38HoaxteC6o0M=; b=oQ+Yz1j+5AP9gOmjTtTjRMXvIG2l11wI+R8ATDNUGxthTSKFJoqPAaZad5RKLWVaUV IdAC51atqRSXqrY481WAerPyUz5dQL/cIDjvRPZwr2POOOuEVCD18FsF/loegrqXCmDa CusD491SGPgvom073PWbZ4P/ACvIU3OgCWyLIE30RwjClhqSZHorUPhdVlE/AwFfKRsb I8TTLAZ+yFYb1GIlKCr87p4MjzdWwb0pcPIWY1BMv06rxdklmzLbfD8lyWytDfqiAhRo lOLB82m0upPr9jn9NaCv0mlMMYyFb2qbCcygjmxN24ymmb93K5StcfK/v08tjgbBeH// he8w== X-Received: by 10.194.76.165 with SMTP id l5mr24614920wjw.14.1359763592072; Fri, 01 Feb 2013 16:06:32 -0800 (PST) MIME-Version: 1.0 Sender: mca@amundsen.com Received: by 10.194.166.36 with HTTP; Fri, 1 Feb 2013 16:06:11 -0800 (PST) In-Reply-To: References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> <-3128426172162859719@unknownmsgid> <022b01ce0085$a4452b90$eccf82b0$@tavis.ca> <6D2125B5-02DE-4016-86BA-38F8FA100DB4@nordsc.com> <3F268583-BC18-412F-8348-16AFB070EC21@nordsc.com> <694EDD73-FAB5-419E-B72D-717F5F7F21BF@nordsc.com> <7338D97E-0362-486B-AAF1-F9CD64813213@nordsc.com> <4522B945ABF34A74A39FCE1A0C68A9D2@gmail.com> <680DF765108749568E54174961CF84C6@gmail.com> From: mike amundsen Date: Fri, 1 Feb 2013 19:06:11 -0500 X-Google-Sender-Auth: eNO_j9C2H_Wb4OFIeajZDCP9KGc Message-ID: Subject: Re: NEW RELATION: action To: Ioseb Dzmanashvili Content-Type: multipart/alternative; boundary=047d7bfcedb2e24c0004d4b2a1d0 X-Gm-Message-State: ALoCoQkkEcjAvL2slZKdj0wFAS/jAuaw0urvqS0MxTgv0X4alqRvbd7j3pgSI82SnATi+YHDh1gp Cc: darrel@tavis.ca, link-relations 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: Sat, 02 Feb 2013 00:06:34 -0000 --047d7bfcedb2e24c0004d4b2a1d0 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Feb 1, 2013 at 7:01 PM, Ioseb Dzmanashvili < ioseb.dzmanashvili@gmail.com> wrote: > Mike, > > > so, the primary reason for offering this is to be able to describe an > unsafe, non-idempotent empty transition using only message metadata (Link > header), right? > > No of course, it can be used in other formats too i believe. > other formats such as in media type bodies? as in the examples I already supplied? or something else? > ioseb > > On Saturday, February 2, 2013 at 3:54 AM, mike amundsen wrote: > > so, the primary reason for offering this is to be able to describe an > unsafe, non-idempotent empty transition using only message metadata (Link > header), right? > > mamund > +1.859.757.1449 > skype: mca.amundsen > http://amundsen.com/blog/ > http://twitter.com/mamund > https://github.com/mamund > http://www.linkedin.com/in/mikeamundsen > > > On Fri, Feb 1, 2013 at 6:44 PM, Ioseb Dzmanashvili < > ioseb.dzmanashvili@gmail.com> wrote: > > Mike, > > > "simple HTTP messages" is also not quantifiable. I have no doubt you > like this design; might even find it to be "simple" I'm not saying it's > "not simple." maybe you have another thing in mind for "simple" that i'm > not getting here. > > Well, what i mean under "simple" is this: having link relation type like > "action" which has very clear and simple purpose(i.e. send an empty POST > request to this URI), it's very easy to filter out these "action" links > from bunch of other links and present to the application user > contextually(i.e. actions available alongside list items, > window/page/screen level actions etc...) without need to rely on: > > * Application level semantics which are described in underlying media type; > * Application specific conventions; > * Additional documentation; > * Some other assumptions; > * etc... > > As i see it it's mostly useful for applications where users are involved > and less valuable for M2M interactions(though it's possible too). > > Under "simple HTTP messages" i mean that HTTP headers and status codes > could be enough in lots of cases. > > > "single-handedly" is something I can't comment upon since i don't know > what you mean here. > > Sorry for confusion, i meant without involving media types help to > describe such kind of interactions. > > > however, i can describe an "empty POST" in HTML, HAL, Cj, and Siren; > proly voiceXML, too. Atom doesn't support any variable definitions for > unsafe transitions (empty or otherwise), but OData's CDSL allows me to > describe an empty POST. > > I do not argue that it's not possible with mentioned formats, and to be > honest i do it all time. Though there are some cons when using these media > types for describing these unsafe interactions. To be clear, HTML allows us > to construct messages the way we want(i.e. inline empty forms, links, > data...), this format is very well understood by browsers and can be > rendered properly according to its structure. > > On the other hand not HAL nor Cj have such possibilities(i.e rendering). > These formats do not offer such possibility to directly embed multiple > "forms" for constructing empty POST requests. Even it's achievable it > doesn't clearly say how to distinguish such elements from the document. > Whereas links(which both formats support fantastically) could be easily > distinguished and grouped from others by rel values and presented > contextually to users. > > Again, it's not that there is no possibility for doing such things but in > my opinion it's not that simple and clear. > > Best regards, > ioseb > > > On Saturday, February 2, 2013 at 3:13 AM, mike amundsen wrote: > > On Fri, Feb 1, 2013 at 5:45 PM, Ioseb Dzmanashvili < > ioseb.dzmanashvili@gmail.com> wrote: > > Mike, > > > 2 - It's not something I am likely to require in a media type design or > in an instance implementation. And if I did, it would proly be an > application-specific use-case; one that i'd solve within the available > media types themselves. > > The approach i'm trying to defend doesn't require media type(s), message > constructions etc... There are a lot of use cases where such kind of simple > interactions just work and most of the interaction can be carried with > simple HTTP messages + Link header field. This is the point of this link > rel, not that it's impossible to implement such functionality with existing > media types. > > > well "there are lots" is most likely an exercise of availability bias :) I > am telling you here that "It's not something *I* am likely to require..." > not making a statement about your work or anyone else's work. > > "simple HTTP messages" is also not quantifiable. I have no doubt you like > this design; might even find it to be "simple" I'm not saying it's "not > simple." maybe you have another thing in mind for "simple" that i'm not > getting here. > > We agree "it's not impossible... with existing media types" - no problem > there. > > > > 3 - Most all media types i deal w/ allow this already and i don't see an > advantage to create a rel value for it. > > Can you please point me to such media type which allows to implement > similar functionality single-handedly? (i'm really interested). > > "single-handedly" is something I can't comment upon since i don't know > what you mean here. > > however, i can describe an "empty POST" in HTML, HAL, Cj, and Siren; proly > voiceXML, too. Atom doesn't support any variable definitions for unsafe > transitions (empty or otherwise), but OData's CDSL allows me to describe an > empty POST. > > > > > That's my view. > > Thanks! :-) > > Cheers, > ioseb > > On Saturday, February 2, 2013 at 2:17 AM, mike amundsen wrote: > > > 1 - This describes a use-case that is pretty rare in my work (an unsafe, > non-idempotent, empty request for a single protocol). > > 2 - It's not something I am likely to require in a media type design or in > an instance implementation. And if I did, it would proly be an > application-specific use-case; one that i'd solve within the available > media types themselves. > > 3 - Most all media types i deal w/ allow this already and i don't see an > advantage to create a rel value for it. > > 4 - I am not a fan of rel values that define protocol-level actions (e.g. > methods) anyway. > > That's my view. > > mamund > +1.859.757.1449 > skype: mca.amundsen > http://amundsen.com/blog/ > http://twitter.com/mamund > https://github.com/mamund > http://www.linkedin.com/in/mikeamundsen > > > On Fri, Feb 1, 2013 at 5:05 PM, Darrel Miller wrote: > > Mike, > > On Fri, Feb 1, 2013 at 4:51 PM, mike amundsen wrote: > > so, "action" is only for sending an empty HTTP.POST request; nothing > else. no other protocol use (XMPP, WS, FTP, etc.) no HTTP.PUT, PATCH, > DELETE, or any other method that might be added to HTTP in the future, > correct? > > > > If another protocol has an equivalent operation which is unsafe and > requires no parameters, then I see no reason why there cannot be a mapping > for that protocol. However, for HTTP the only other method I can imagine > that might map is DELETE. However, that would then require the > specification of a link-extension parameter to communicate what method to > use. Personally, I would choose to limit it to POST. > > Darrel > > > > > > > > > --047d7bfcedb2e24c0004d4b2a1d0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Feb 1, 2013 at 7:01 PM, Ioseb Dzmanashvili <ioseb.dzman= ashvili@gmail.com> wrote:
Mike,

>= =A0so, the primary reason for offering this is to be able to describe an un= safe, non-idempotent empty transition using only message metadata (Link hea= der), right?

No of course, it can be used in other formats too= i believe.=A0
=A0
other formats such as i= n media type bodies? as in the examples I already supplied? or something el= se?


ioseb
=20

On Saturday, February 2, 2013 at= 3:54 AM, mike amundsen wrote:

so, the primary reason for offerin= g this is to be able to describe an unsafe, non-idempotent empty transition= using only message metadata (Link header), right?

mamund


On Fri, Feb 1, 2013 at 6:44 PM, Ioseb Dzmanashvili <ioseb.dzmanashvili@gmail.com> wrote:
Mike,

> "si= mple HTTP messages" is also not quantifiable. I have no doubt you like= this design; might even find it to be "simple" I'm not sayin= g it's "not simple." maybe you have another thing in mind for= "simple" that i'm not getting here.

Well, what i mean under "simple" is thi= s: having link relation type like "action" which has very clear a= nd simple purpose(i.e. send an empty POST request to this URI), it's ve= ry easy to filter out these "action" links from bunch of other li= nks and present to the application user contextually(i.e. actions available= alongside list items, window/page/screen level actions etc...) without nee= d to rely on:

* Application level semantics which are described in un= derlying media type;
* Application specific conventions;
* Additional documentation;
* Some other assumptions;
* etc...

As i see it it's mostly useful f= or applications where users are involved and less valuable for M2M interact= ions(though it's possible too).

Under "si= mple HTTP messages" i mean that HTTP headers and status codes could be= enough in lots of cases.

> "single-handedly" is something I ca= n't comment upon since i don't know what you mean here.
<= br>
Sorry for confusion, i meant without involving media ty= pes help to describe such kind of interactions.

> however, i can describe an "empty POST&q= uot; in HTML, HAL, Cj, and Siren; proly voiceXML, too. Atom doesn't sup= port any variable definitions for unsafe transitions (empty or otherwise), = but OData's CDSL allows me to describe an empty POST.

I do not argue that it's not possible with me= ntioned formats, and to be honest i do it all time. Though there are some c= ons when using these media types for describing these unsafe interactions. = To be clear, HTML allows us to construct messages the way we want(i.e. inli= ne empty forms, links, data...), this format is very well understood by bro= wsers and can be rendered properly according to its structure.=A0

On the other hand not HAL nor Cj have such possibilitie= s(i.e rendering). These formats do not offer such possibility to directly e= mbed multiple "forms" for constructing empty POST requests. Even = it's achievable it doesn't clearly say how to distinguish such elem= ents from the document. Whereas links(which both formats support fantastica= lly) could be easily distinguished and grouped from others by rel values an= d presented contextually to users.

Again, it's not that there is no possibility for do= ing such things but in my opinion it's not that simple and clear.
=

Best regards,
ioseb


=20

On Saturday, February 2, 2013 at= 3:13 AM, mike amundsen wrote:

On Fri, Feb 1, 2013 at 5:45 PM, Ioseb D= zmanashvili <ioseb.dzmanashvili@gmail.com> wrote:=
Mike,

> 2 - It&#= 39;s not something I am likely to require in a media type design or in an i= nstance implementation. And if I did, it would proly be an application-spec= ific use-case; one that i'd solve within the available media types them= selves.=A0

The approach i'm trying to defend doesn't= require media type(s), message constructions etc... There are a lot of use= cases where such kind of simple interactions just work and most of the int= eraction can be carried with simple HTTP messages + Link header field. This= is the point of this link rel, not that it's impossible to implement s= uch functionality with existing media types.

well "there are lots"= ; is most likely an exercise of availability bias :) I am telling you here = that "It's not something *I* am likely to require..." not mak= ing a statement about your work or anyone else's work.

"simple HTTP messages" is also not quantifiab= le. I have no doubt you like this design; might even find it to be "si= mple" I'm not saying it's "not simple." maybe you ha= ve another thing in mind for "simple" that i'm not getting he= re.

We agree "it's not impossible... with existing= media types" - no problem there.


> 3 - Most all media types i deal w/ allow= this already and i don't see an advantage to create a rel value for it= .

Can you please point me to such media type= which allows to implement similar functionality single-handedly? (i'm = really interested).
"single-handedly" is something I ca= n't comment upon since i don't know what you mean here.=A0

however, i can describe an "empty POST" in HTML,= HAL, Cj, and Siren; proly voiceXML, too. Atom doesn't support any vari= able=A0definitions for unsafe transitions=A0(empty or otherwise), but OData= 's CDSL allows me to=A0describe=A0an empty POST.
=A0

> That's my view.

Thanks! :-)

Cheers,
ioseb
=20

On Saturday, February 2, 2013 at= 2:17 AM, mike amundsen wrote:


1 - This describes a use= -case that is pretty rare in my work (an unsafe, non-idempotent, empty requ= est for a single protocol).

2 - It's not something I= am likely to require in a media type design or in an instance implementati= on. And if I did, it would proly be an application-specific use-case; one t= hat i'd solve within the available media types themselves.=A0

3 - Most all media types i deal w/ allow this already a= nd i don't see an advantage to create a rel value for it.
4 - I am not a fan of rel values that define protocol-level act= ions (e.g. methods) anyway.

That's my view.



On Fri, Feb 1, 2013 at 5:05 PM, Darrel Miller <darrel.m= iller@gmail.com> wrote:
Mike,

On Fri, Feb 1, 2013 at 4:51 P= M, mike amundsen <mamund@yahoo.com> wrote:
so, "action" is only for sending an empty HTTP.POST request;= nothing else. no other protocol use (XMPP, WS, FTP, etc.) no HTTP.PUT, PAT= CH, DELETE, or any other method that might be added to HTTP in the future, = correct?


If a= nother protocol has an equivalent operation which is unsafe and requires no= parameters, then =A0I see no reason why there cannot be a mapping for that= protocol. =A0However, for HTTP the only other method I can imagine that mi= ght map is DELETE. =A0However, that would then require the specification of= a link-extension parameter to communicate what method to use. =A0Personall= y, I would choose to limit it to POST.

Darrel=A0
=A0
=

=20 =20 =20 =20


=20 =20 =20 =20


=20 =20 =20 =20 =20


--047d7bfcedb2e24c0004d4b2a1d0-- From ioseb.dzmanashvili@gmail.com Fri Feb 1 16:11:22 2013 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 0BBAB21E8041 for ; Fri, 1 Feb 2013 16:11:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.34 X-Spam-Level: X-Spam-Status: No, score=-1.34 tagged_above=-999 required=5 tests=[AWL=-0.742, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_55=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 jm3-+ALsNFDG for ; Fri, 1 Feb 2013 16:11:13 -0800 (PST) Received: from mail-ea0-f170.google.com (mail-ea0-f170.google.com [209.85.215.170]) by ietfa.amsl.com (Postfix) with ESMTP id 5849C21E8089 for ; Fri, 1 Feb 2013 16:11:12 -0800 (PST) Received: by mail-ea0-f170.google.com with SMTP id a11so1945100eaa.15 for ; Fri, 01 Feb 2013 16:11:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:message-id:in-reply-to:references :subject:x-mailer:mime-version:content-type; bh=T/6+MAv77d/v663DMmJo61UMY7TVkw77XK4f3BnY20k=; b=ZdWgJwFC1Hla29OvF+IfqUKNCxjPaFJKO+sePW1kCxfgKnu+pjX27Ms9dIOBMoYPlS LNLnaLUy3mdPaxXm3UlI1X/nGt32bJB6fChlRe8lHl9j9KxgrVOxg0V1KcKNzZcS/pPg C0ayqvwPZ7BGDfe9wPP3QP/zJAfiMGUVnLPyLjEj33GHJkPYQzgFDiM1hgCTjxMXTB8U BIq9SNi7s+kUWdpoefeQVqst7shDMkyNO6Fp47gtPF3UhBgWTyRfw62FaGGs40H1h6dw a6X5GxHetajAwEIO5QLO2xTQ3NrUnoo776eUs0nVuFjHz6NpYMtGGCQj/jgRoYX2JCce FOGA== X-Received: by 10.14.198.198 with SMTP id v46mr44946132een.4.1359763871475; Fri, 01 Feb 2013 16:11:11 -0800 (PST) Received: from [192.168.1.3] ([176.73.174.236]) by mx.google.com with ESMTPS id t4sm15016977eel.0.2013.02.01.16.11.09 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 01 Feb 2013 16:11:10 -0800 (PST) Date: Sat, 2 Feb 2013 04:11:10 +0400 From: Ioseb Dzmanashvili To: mike amundsen Message-ID: In-Reply-To: References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> <-3128426172162859719@unknownmsgid> <022b01ce0085$a4452b90$eccf82b0$@tavis.ca> <6D2125B5-02DE-4016-86BA-38F8FA100DB4@nordsc.com> <3F268583-BC18-412F-8348-16AFB070EC21@nordsc.com> <694EDD73-FAB5-419E-B72D-717F5F7F21BF@nordsc.com> <7338D97E-0362-486B-AAF1-F9CD64813213@nordsc.com> <4522B945ABF34A74A39FCE1A0C68A9D2@gmail.com> <680DF765108749568E54174961CF84C6@gmail.com> Subject: Re: NEW RELATION: action X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="510c599e_399d6ba1_28a" Cc: darrel@tavis.ca, link-relations 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: Sat, 02 Feb 2013 00:11:22 -0000 --510c599e_399d6ba1_28a Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Mike, > other formats such as in media type bodies? as in the examples I already supplied? or something else? Yes. Below is the example I posted to this thread in earlier messages: ----------------------- > GET /posts HTTP/1.1 > Host: domain.org > HTTP/1.1 200 OK > Content-Type: application/vnd.something+json > Content-Length: ... {"document": { "href": "/posts" "links": { "item": [{ "href": "/posts/1", "title": "Post One Title", "links": { "action": { "href": "/posts/1/publisher", "title": "Publish" }, "replies": { "href": "/posts/1/replies", "title": "Comments" }, "edit": { "href": "/posts/1", "title": "Edit post" } } }, { "href": "/posts/2", "title": "Post Two Title", "links": { "action": { "href": "/posts/2/publisher", "title": "Publish" }, "replies": { "href": "/posts/2/replies", "title": "Comments" }, "edit": { "href": "/posts/2", "title": "Edit post" } } }] } }} Here we have document with hierarchical links(no specific format, just format i frequently use for my implementations). Now if i want to present these links visually i've all information which may be perfectly rendered on mobile devices, for example lets say simple list. Post title is enough for application user. The "action" link relation has enough semantics for application to render it as a "Publish" button alongside the title and if user decides to "publish" the post there is no need for application to: a) go to the server and retrieve full representation in whatever media type; b) modify only one attribute of the retrieved representatin; and c) send modified representation to the server with PUT method. Instead simple POST request can be sent to the resource which knows what to do with the post's state. ioseb On Saturday, February 2, 2013 at 4:06 AM, mike amundsen wrote: > On Fri, Feb 1, 2013 at 7:01 PM, Ioseb Dzmanashvili wrote: > > Mike, > > > > > so, the primary reason for offering this is to be able to describe an unsafe, non-idempotent empty transition using only message metadata (Link header), right? > > > > No of course, it can be used in other formats too i believe. > > other formats such as in media type bodies? as in the examples I already supplied? or something else? > > > > > ioseb > > > > On Saturday, February 2, 2013 at 3:54 AM, mike amundsen wrote: > > > > > so, the primary reason for offering this is to be able to describe an unsafe, non-idempotent empty transition using only message metadata (Link header), right? > > > > > > mamund > > > +1.859.757.1449 (tel:%2B1.859.757.1449) > > > skype: mca.amundsen > > > http://amundsen.com/blog/ > > > http://twitter.com/mamund > > > https://github.com/mamund > > > http://www.linkedin.com/in/mikeamundsen > > > > > > On Fri, Feb 1, 2013 at 6:44 PM, Ioseb Dzmanashvili wrote: > > > > Mike, > > > > > > > > > "simple HTTP messages" is also not quantifiable. I have no doubt you like this design; might even find it to be "simple" I'm not saying it's "not simple." maybe you have another thing in mind for "simple" that i'm not getting here. > > > > > > > > Well, what i mean under "simple" is this: having link relation type like "action" which has very clear and simple purpose(i.e. send an empty POST request to this URI), it's very easy to filter out these "action" links from bunch of other links and present to the application user contextually(i.e. actions available alongside list items, window/page/screen level actions etc...) without need to rely on: > > > > > > > > * Application level semantics which are described in underlying media type; > > > > * Application specific conventions; > > > > * Additional documentation; > > > > * Some other assumptions; > > > > * etc... > > > > > > > > As i see it it's mostly useful for applications where users are involved and less valuable for M2M interactions(though it's possible too). > > > > > > > > Under "simple HTTP messages" i mean that HTTP headers and status codes could be enough in lots of cases. > > > > > > > > > "single-handedly" is something I can't comment upon since i don't know what you mean here. > > > > > > > > Sorry for confusion, i meant without involving media types help to describe such kind of interactions. > > > > > > > > > however, i can describe an "empty POST" in HTML, HAL, Cj, and Siren; proly voiceXML, too. Atom doesn't support any variable definitions for unsafe transitions (empty or otherwise), but OData's CDSL allows me to describe an empty POST. > > > > > > > > I do not argue that it's not possible with mentioned formats, and to be honest i do it all time. Though there are some cons when using these media types for describing these unsafe interactions. To be clear, HTML allows us to construct messages the way we want(i.e. inline empty forms, links, data...), this format is very well understood by browsers and can be rendered properly according to its structure. > > > > > > > > On the other hand not HAL nor Cj have such possibilities(i.e rendering). These formats do not offer such possibility to directly embed multiple "forms" for constructing empty POST requests. Even it's achievable it doesn't clearly say how to distinguish such elements from the document. Whereas links(which both formats support fantastically) could be easily distinguished and grouped from others by rel values and presented contextually to users. > > > > > > > > Again, it's not that there is no possibility for doing such things but in my opinion it's not that simple and clear. > > > > > > > > Best regards, > > > > ioseb > > > > > > > > > > > > > > > > On Saturday, February 2, 2013 at 3:13 AM, mike amundsen wrote: > > > > > > > > > > > > > On Fri, Feb 1, 2013 at 5:45 PM, Ioseb Dzmanashvili wrote: > > > > > > Mike, > > > > > > > > > > > > > 2 - It's not something I am likely to require in a media type design or in an instance implementation. And if I did, it would proly be an application-specific use-case; one that i'd solve within the available media types themselves. > > > > > > > > > > > > The approach i'm trying to defend doesn't require media type(s), message constructions etc... There are a lot of use cases where such kind of simple interactions just work and most of the interaction can be carried with simple HTTP messages + Link header field. This is the point of this link rel, not that it's impossible to implement such functionality with existing media types. > > > > > > > > > > well "there are lots" is most likely an exercise of availability bias :) I am telling you here that "It's not something *I* am likely to require..." not making a statement about your work or anyone else's work. > > > > > > > > > > "simple HTTP messages" is also not quantifiable. I have no doubt you like this design; might even find it to be "simple" I'm not saying it's "not simple." maybe you have another thing in mind for "simple" that i'm not getting here. > > > > > > > > > > We agree "it's not impossible... with existing media types" - no problem there. > > > > > > > > > > > > > > > > > > 3 - Most all media types i deal w/ allow this already and i don't see an advantage to create a rel value for it. > > > > > > > > > > > > Can you please point me to such media type which allows to implement similar functionality single-handedly? (i'm really interested). > > > > > "single-handedly" is something I can't comment upon since i don't know what you mean here. > > > > > > > > > > however, i can describe an "empty POST" in HTML, HAL, Cj, and Siren; proly voiceXML, too. Atom doesn't support any variable definitions for unsafe transitions (empty or otherwise), but OData's CDSL allows me to describe an empty POST. > > > > > > > > > > > > > > > > > > That's my view. > > > > > > > > > > > > Thanks! :-) > > > > > > > > > > > > Cheers, > > > > > > ioseb > > > > > > > > > > > > > > > > > > On Saturday, February 2, 2013 at 2:17 AM, mike amundsen wrote: > > > > > > > > > > > > > > > > > > > > 1 - This describes a use-case that is pretty rare in my work (an unsafe, non-idempotent, empty request for a single protocol). > > > > > > > > > > > > > > 2 - It's not something I am likely to require in a media type design or in an instance implementation. And if I did, it would proly be an application-specific use-case; one that i'd solve within the available media types themselves. > > > > > > > > > > > > > > 3 - Most all media types i deal w/ allow this already and i don't see an advantage to create a rel value for it. > > > > > > > > > > > > > > 4 - I am not a fan of rel values that define protocol-level actions (e.g. methods) anyway. > > > > > > > > > > > > > > That's my view. > > > > > > > > > > > > > > mamund > > > > > > > +1.859.757.1449 (tel:%2B1.859.757.1449) > > > > > > > skype: mca.amundsen > > > > > > > http://amundsen.com/blog/ > > > > > > > http://twitter.com/mamund > > > > > > > https://github.com/mamund > > > > > > > http://www.linkedin.com/in/mikeamundsen > > > > > > > > > > > > > > On Fri, Feb 1, 2013 at 5:05 PM, Darrel Miller wrote: > > > > > > > > Mike, > > > > > > > > > > > > > > > > On Fri, Feb 1, 2013 at 4:51 PM, mike amundsen wrote: > > > > > > > > > so, "action" is only for sending an empty HTTP.POST request; nothing else. no other protocol use (XMPP, WS, FTP, etc.) no HTTP.PUT, PATCH, DELETE, or any other method that might be added to HTTP in the future, correct? > > > > > > > > > > > > > > > > > > > > > > > > > If another protocol has an equivalent operation which is unsafe and requires no parameters, then I see no reason why there cannot be a mapping for that protocol. However, for HTTP the only other method I can imagine that might map is DELETE. However, that would then require the specification of a link-extension parameter to communicate what method to use. Personally, I would choose to limit it to POST. > > > > > > > > > > > > > > > > Darrel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --510c599e_399d6ba1_28a Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Mike,

> other forma= ts such as in media type bodies=3F as in the examples I already supplied=3F= or something else=3F

Yes. Below is the example = I posted to this thread in earlier messages:
------------------= -----

> GET /posts HTTP/1.1
&g= t; Host: domain.org

> HTTP/1.1 200 OK
> Content-Type: application/vnd.something+json
> Conte= nt-Length: ...

=7B=22document=22: =7B
= = =22href=22: =22/posts=22
=22links=22: =7B
=22item=22= : =5B=7B
=22href=22: =22/posts/1=22,
=22title=22:= =22Post One Title=22,
=22links=22: =7B
=22actio= n=22: =7B =22href=22: =22/posts/1/publisher=22, =22title=22: =22Publish=22= =7D,
=22replies=22: =7B =22href=22: =22/posts/1/replies=22,= =22title=22: =22Comments=22 =7D,
=22edit=22: =7B =22href=22= : =22/posts/1=22, =22title=22: =22Edit post=22 =7D
=7D
=7D, =7B
=22href=22: =22/posts/2=22,
=22title= =22: =22Post Two Title=22,
=22links=22: =7B
=22a= ction=22: =7B =22href=22: =22/posts/2/publisher=22, =22title=22: =22Publi= sh=22 =7D,
=22replies=22: =7B =22href=22: =22/posts/2/replie= s=22, =22title=22: =22Comments=22 =7D,
=22edit=22: =7B =22hr= ef=22: =22/posts/2=22, =22title=22: =22Edit post=22 =7D
=7D
=7D=5D
=7D
=7D=7D

= Here we have document with hierarchical links(no specific format, just fo= rmat i frequently use for my implementations). Now if i want to present t= hese links visually i've all information which may be perfectly rendered = on mobile devices, for example lets say simple list. Post title is enough= for application user. The =22action=22 link relation has enough semantic= s for application to render it as a =22Publish=22 button alongside the ti= tle and if user decides to =22publish=22 the post there is no need for ap= plication to: a) go to the server and retrieve full representation in wha= tever media type; b) modify only one attribute of the retrieved represent= atin; and c) send modified representation to the server with PUT method. = Instead simple POST request can be sent to the resource which knows what = to do with the post's state.

ioseb
=20

On Saturday, =46ebruar= y 2, 2013 at 4:06 AM, mike amundsen wrote:

On =46ri, =46eb 1, 2013 at 7:01 PM, I= oseb Dzmanashvili <ioseb.dzmanashvili=40gma= il.com> wrote:
Mike,

> so, th= e primary reason for offering this is to be able to describe an unsafe, n= on-idempotent empty transition using only message metadata (Link header),= right=3F

No of course, it can be used in other formats t= oo i believe. 
 
other f= ormats such as in media type bodies=3F as in the examples I already suppl= ied=3F or something else=3F


ioseb
=20

On Saturday, =46ebruary = 2, 2013 at 3:54 AM, mike amundsen wrote:

so, the primary reason for offer= ing this is to be able to describe an unsafe, non-idempotent empty transi= tion using only message metadata (Link header), right=3F

mamund


On =46ri, =46eb 1, 2013 at 6:44 PM, Ioseb Dzmanashvili <ioseb.dzmanashvili=40gmail.com> wr= ote:
Mike,

> =22sim= ple HTTP messages=22 is also not quantifiable. I have no doubt you like t= his design; might even find it to be =22simple=22 I'm not saying it's =22= not simple.=22 maybe you have another thing in mind for =22simple=22 that= i'm not getting here.

Well, what i mean under =22simple=22 is this: h= aving link relation type like =22action=22 which has very clear and simpl= e purpose(i.e. send an empty POST request to this URI), it's very easy to= filter out these =22action=22 links from bunch of other links and presen= t to the application user contextually(i.e. actions available alongside l= ist items, window/page/screen level actions etc...) without need to rely = on:

* Application level semantics which are described in = underlying media type;
* Application specific conventions;
* Additional documentation;
* Some other assumptions;
* etc...

As i see it it's mostly useful for= applications where users are involved and less valuable for M2M interact= ions(though it's possible too).

Under =22simple = HTTP messages=22 i mean that HTTP headers and status codes could be enoug= h in lots of cases.

> =22single-handedly=22 is something I can't = comment upon since i don't know what you mean here.

<= /div>
Sorry for confusion, i meant without involving media types help= to describe such kind of interactions.

> however, i can describe an =22empty POST=22= in HTML, HAL, Cj, and Siren; proly voiceXML, too. Atom doesn't support a= ny variable definitions for unsafe transitions (empty or otherwise), but = OData's CDSL allows me to describe an empty POST.

I do not argue that it's not possible with ment= ioned formats, and to be honest i do it all time. Though there are some c= ons when using these media types for describing these unsafe interactions= . To be clear, HTML allows us to construct messages the way we want(i.e. = inline empty forms, links, data...), this format is very well understood = by browsers and can be rendered properly according to its structure. = ;

On the other hand not HAL nor Cj have such possibilit= ies(i.e rendering). These formats do not offer such possibility to direct= ly embed multiple =22forms=22 for constructing empty POST requests. Even = it's achievable it doesn't clearly say how to distinguish such elements f= rom the document. Whereas links(which both formats support fantastically)= could be easily distinguished and grouped from others by rel values and = presented contextually to users.

Again, it's not that there is no possibility for doin= g such things but in my opinion it's not that simple and clear.

Best regards,
ioseb


=20

On Saturday, =46ebruary = 2, 2013 at 3:13 AM, mike amundsen wrote:

On =46ri, =46eb 1, 2013 at 5:45 PM, I= oseb Dzmanashvili <ioseb.dzmanashvili=40gma= il.com> wrote:
Mike,

> 2 - It= 's not something I am likely to require in a media type design or in an i= nstance implementation. And if I did, it would proly be an application-sp= ecific use-case; one that i'd solve within the available media types them= selves. 

The approach i'm trying to defend doesn't requi= re media type(s), message constructions etc... There are a lot of use cas= es where such kind of simple interactions just work and most of the inter= action can be carried with simple HTTP messages + Link header field. This= is the point of this link rel, not that it's impossible to implement suc= h functionality with existing media types.

well =22there are lots=22 is= most likely an exercise of availability bias :) I am telling you here th= at =22It's not something *I* am likely to require...=22 not making a stat= ement about your work or anyone else's work.

=22simple HTTP messages=22 is also not quantifiable. = I have no doubt you like this design; might even find it to be =22simple=22= I'm not saying it's =22not simple.=22 maybe you have another thing in mi= nd for =22simple=22 that i'm not getting here.

We agree =22it's not impossible... with existing medi= a types=22 - no problem there.


> 3 - Most all media types i deal w/ all= ow this already and i don't see an advantage to create a rel value for it= .

Can you please point me to such media ty= pe which allows to implement similar functionality single-handedly=3F (i'= m really interested).
=22single-handedly=22 is something I can't = comment upon since i don't know what you mean here. 

<= /div>
however, i can describe an =22empty POST=22 in HTML, HAL, Cj, a= nd Siren; proly voiceXML, too. Atom doesn't support any variable def= initions for unsafe transitions (empty or otherwise), but OData's CD= SL allows me to describe an empty POST.
 

> That's my= view.

Thanks=21 :-)
<= br>
Cheers,
ioseb
=20

On Saturday, =46ebruary = 2, 2013 at 2:17 AM, mike amundsen wrote:


1 - This describes a u= se-case that is pretty rare in my work (an unsafe, non-idempotent, empty = request for a single protocol).

2 - It's not something= I am likely to require in a media type design or in an instance implemen= tation. And if I did, it would proly be an application-specific use-case;= one that i'd solve within the available media types themselves. 

3 - Most all media types i deal w/ allow this already= and i don't see an advantage to create a rel value for it.
4 - I am not a fan of rel values that define protocol-level a= ctions (e.g. methods) anyway.

That's my view.



On =46ri, =46eb 1, 2013 at 5:05 PM, Darrel Miller <darrel.miller=40gmail.com> wrote:
Mike,

On =46ri, =46eb 1, 2013= at 4:51 PM, mike amundsen <mamund=40yahoo.com><= /span> wrote:
so, =22action=22 is only for sending an empty HTTP.POST request; not= hing else. no other protocol use (XMPP, WS, =46TP, etc.) no HTTP.PUT, PAT= CH, DELETE, or any other method that might be added to HTTP in the future= , correct=3F

<= /div>
If another protocol has an equivalent operation which is unsafe= and requires no parameters, then  I see no reason why there cannot = be a mapping for that protocol.  However, for HTTP the only other me= thod I can imagine that might map is DELETE.  However, that would th= en require the specification of a link-extension parameter to communicate= what method to use.  Personally, I would choose to limit it to POST= .

Darrel 
 

=20 =20 =20 =20


=20 =20 =20 =20


=20 =20 =20 =20


=20 =20 =20 =20 =20

--510c599e_399d6ba1_28a-- From ioseb.dzmanashvili@gmail.com Fri Feb 1 16:14:57 2013 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 E75D721E805A for ; Fri, 1 Feb 2013 16:14:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.183 X-Spam-Level: X-Spam-Status: No, score=-2.183 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, J_CHICKENPOX_64=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 o2aijjwAzcMe for ; Fri, 1 Feb 2013 16:14:55 -0800 (PST) Received: from mail-ea0-f178.google.com (mail-ea0-f178.google.com [209.85.215.178]) by ietfa.amsl.com (Postfix) with ESMTP id 634E221E8041 for ; Fri, 1 Feb 2013 16:14:55 -0800 (PST) Received: by mail-ea0-f178.google.com with SMTP id a14so2035460eaa.9 for ; Fri, 01 Feb 2013 16:14:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:message-id:in-reply-to:references :subject:x-mailer:mime-version:content-type; bh=p6s45R78jwsZMzHcg0nMJ/qL1V9iABjQeongZ/VNKRg=; b=gZR10ghTOslZAqiLkkyx/H6rkRleXnkx9n9aW3Sys+4gPN9i5NQywe956QQK5JnPtk Nl0safqjRWIv/6zYIx+n9Gv/aZBuo5wHowKhaAV9K9GtjP9CGvTQFXtXXhxEGLvkI/2r 1YUeALm4iZr12Cx5A1Pd4PAWYqx2cH8Tq/y5vfaUvGeNasE67dcOM/IQDYRWcOaNvau/ CFKa2b4U0Fze16SyeGh21gFvmhtH1lSpfdyOSV3ArAuMNN3+gGghnG0z7rGwCtD5jFdD BA196U5oqyE4761RG9qN3+MqM51FiCvnZ1EFTaOIEXRArIslzTSYSr2QcKAxQBvLOBZ8 fHCQ== X-Received: by 10.14.223.137 with SMTP id v9mr45248378eep.22.1359764094510; Fri, 01 Feb 2013 16:14:54 -0800 (PST) Received: from [192.168.1.3] ([176.73.174.236]) by mx.google.com with ESMTPS id q5sm15001436eep.11.2013.02.01.16.14.52 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 01 Feb 2013 16:14:53 -0800 (PST) Date: Sat, 2 Feb 2013 04:14:53 +0400 From: Ioseb Dzmanashvili To: mike amundsen Message-ID: In-Reply-To: References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> <-3128426172162859719@unknownmsgid> <022b01ce0085$a4452b90$eccf82b0$@tavis.ca> <6D2125B5-02DE-4016-86BA-38F8FA100DB4@nordsc.com> <3F268583-BC18-412F-8348-16AFB070EC21@nordsc.com> <694EDD73-FAB5-419E-B72D-717F5F7F21BF@nordsc.com> <7338D97E-0362-486B-AAF1-F9CD64813213@nordsc.com> <4522B945ABF34A74A39FCE1A0C68A9D2@gmail.com> <680DF765108749568E54174961CF84C6@gmail.com> <7EBC6976FB50437AA1BCA0079854D359@gmail.com> Subject: Re: NEW RELATION: action X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="510c5a7d_43b2bc58_28a" Cc: darrel@tavis.ca, link-relations 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: Sat, 02 Feb 2013 00:14:58 -0000 --510c5a7d_43b2bc58_28a Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Mike, > Since one of your key cases is that your proposal bypasses describing the transition within a message body, I suppose the only difference is the one you think is important, right? "bypassing" message body is one of the possibilities and this we get for free because of Link header field, in other response i posted another example where "action" links are embedded in body. Another option is that existence of well defined link relation makes it reusable in different implementation without the need to redefine "action" semantics or rely on some specific human readable documentation(which is not reusable across organisations for example). ioseb On Saturday, February 2, 2013 at 4:05 AM, mike amundsen wrote: > On Fri, Feb 1, 2013 at 6:58 PM, Ioseb Dzmanashvili wrote: > > Mike, > > > > Let me ask question before Darrel responds. > > > > > Darrel: > > > did you just make a case for the abiltiy to do unsafe non-idempotent empty requests in OData and HAL w/o using this new rel value? > > > > How this thing: > > > > > target="Movies(6)/Checkout" > > title="Checkout Donnie Darko" /> > > > > is different from: Link: ; rel="action http://otherserver/$metadata#MyEntities.Checkout"; title="Checkout Donnie Darko" > > > > Other than it's a part of the media type itself and is not directly useful outside the OData format? > > Since one of your key cases is that your proposal bypasses describing the transition within a message body, I suppose the only difference is the one you think is important, right? > > > > > Also, how it's possible to implement this in HAL without introducing some additional structure(extending the format or introducing some specific convention on particular application implementation level) > > In my (limited) use of HAL, all transition semantics (methods, bodies, etc.) are supplied in human readable documentation and associated w/ a rel value. I just write documentation that sez pass no arguments in the body, method=POST and associate that w/ my selected link rel value. > > > > > Cheers, > > ioseb > > > > On Saturday, February 2, 2013 at 3:46 AM, mike amundsen wrote: > > > Darrel: > > > > > > did you just make a case for the abiltiy to do unsafe non-idempotent empty requests in OData and HAL w/o using this new rel value? > > > > > > mamund > > > +1.859.757.1449 (tel:%2B1.859.757.1449) > > > skype: mca.amundsen > > > http://amundsen.com/blog/ > > > http://twitter.com/mamund > > > https://github.com/mamund > > > http://www.linkedin.com/in/mikeamundsen > > > > > > On Fri, Feb 1, 2013 at 6:45 PM, Darrel Miller wrote: > > > > > > > > Mike, > > > > > > > > On Fri, Feb 1, 2013 at 6:13 PM, mike amundsen wrote: > > > > > > > > > > however, i can describe an "empty POST" in HTML, HAL, Cj, and Siren; proly voiceXML, too. Atom doesn't support any variable definitions for unsafe transitions (empty or otherwise), but OData's CDSL allows me to describe an empty POST. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Unless, Mr. Kelly did some magic on HAL while I wasn't looking there is nothing in the media type that allows you to include hypermedia controls for unsafe interactions without deferring to a link relation. > > > > > > > > Also, OData has also come to the same conclusion that the concept of an "action" is necessary, which is why they invented OData "Actions". http://www.odata.org/blog/2011/10/7/actions-in-odata > > > > > > > > > > > > Darrel > > > > > > > > > > > > > > > --510c5a7d_43b2bc58_28a Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Mike,

> Since one o= f your key cases is that your proposal bypasses describing the transition= within a message body, I suppose the only difference is the one you thin= k is important, right=3F

=22bypassing=22 message= body is one of the possibilities and this we get for free because of Lin= k header field, in other response i posted another example where =22actio= n=22 links are embedded in body. Another option is that existence of well= defined link relation makes it reusable in different implementation with= out the need to redefine =22action=22 semantics or rely on some specific = human readable documentation(which is not reusable across organisations f= or example).

ioseb
=20

On Saturday, =46ebruar= y 2, 2013 at 4:05 AM, mike amundsen wrote:

On =46ri, =46eb 1, 2013 at 6:58 PM, I= oseb Dzmanashvili <ioseb.dzmanashvili=40gma= il.com> wrote:
Mike,

Let me ask question b= efore Darrel responds.

> Darrel:
> did you just make a case for the abiltiy to do unsafe non-idempot= ent empty requests in OData and HAL w/o using this new rel value=3F
=

How this thing:

          target=3D=22Movies(6)/Checkout=22=  
          title=3D=22Checkout D= onnie Darko=22 />

is different from: Link: &l= t;Movies(6)/Checkout>; rel=3D=22action http://othe= rserver/=24metadata=23MyEntities.Checkout=22; title=3D=22Checkout Don= nie Darko=22

Other than it's a part of the media type i= tself and is not directly useful outside the OData format=3F
 
Since one of your key cases is t= hat your proposal bypasses describing the transition within a message bod= y, I suppose the only difference is the one you think is important, right= =3F
 

Also, = how it's possible to implement this in HAL without introducing some addit= ional structure(extending the format or introducing some specific convent= ion on particular application implementation level)
 
In my (limited) use of HAL, all = transition semantics (methods, bodies, etc.) are supplied in human readab= le documentation and associated w/ a rel value. I just write documentatio= n that sez pass no arguments in the body, method=3DPOST and associate tha= t w/ my selected link rel value. 


Che= ers,
ioseb

On Saturday,= =46ebruary 2, 2013 at 3:46 AM, mike amundsen wrote:
Darrel:

did you ju= st make a case for the abiltiy to do unsafe non-idempotent empty requests= in OData and HAL w/o using this new rel value=3F



On =46ri, =46eb 1, 2013 at 6:45 PM, Darrel Miller <darrel.miller=40gmail.com> wrote:

Mike,

On =46ri, =46= eb 1, 2013 at 6:13 PM, mike amundsen <mamund=40yahoo.co= m> wrote:

however, i can describe an =22empty POST=22 in HTML, HAL, Cj, and Si= ren; proly voiceXML, too. Atom doesn't support any variable definiti= ons for unsafe transitions (empty or otherwise), but OData's CDSL al= lows me to describe an empty POST.
 

Unless, Mr. Kelly did some magic on HAL while I wasn't looking there is = nothing in the media type that allows you to include hypermedia controls = for unsafe interactions without deferring to a link relation.

Also, OData has also come to the same conclusion that= the concept of an =22action=22 is necessary, which is why they invented = OData =22Actions=22.  http://www.odata.org/blog/= 2011/10/7/actions-in-odata


Darrel


 

=20 =20 =20 =20


=20 =20 =20 =20 =20

--510c5a7d_43b2bc58_28a-- From darrel.miller@gmail.com Fri Feb 1 16:29:44 2013 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 523ED1F0CFE for ; Fri, 1 Feb 2013 16:29:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 D38Ab25uW5YT for ; Fri, 1 Feb 2013 16:29:43 -0800 (PST) Received: from mail-la0-x231.google.com (la-in-x0231.1e100.net [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 8791021F8EF6 for ; Fri, 1 Feb 2013 16:29:43 -0800 (PST) Received: by mail-la0-f49.google.com with SMTP id fs13so3204251lab.22 for ; Fri, 01 Feb 2013 16:29:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rMlHLC2JU8TefHP5YhyBPaPk0fZKImOcgWWwbYwk0BM=; b=GgzWH1LrGN3AXb0bfzvS8lOov1/aFVktGT3isNZr6BktKBbOFZGs9tNMeVHxlwDfit 4vZlFwkVPF1LS4fW7eNxd4Ut/Ip2s7JRDx7Tbq7Y+QrJ5bq+Tm91e27d8gvz5V/sPNjk RWa86Ic1G/1n9PZuaeyuyh/WdLWN8MIUwt6422D2KUta1tA7yzB8UQz9sIr6cmSgfMvL IsTx3vdXuuNi3Psp7l5kdheQcFysjFl5MUJswz4xkIKcG7WBleke9U+yGoG9aTpulElz 3lNOY7Uda1/M79/kPT+vzj4BwJvCUsBTm2XmFGxQILsQuiZJaAYVQfG2kFV0x41hKCEv gv4A== MIME-Version: 1.0 X-Received: by 10.152.144.71 with SMTP id sk7mr12773779lab.29.1359764982305; Fri, 01 Feb 2013 16:29:42 -0800 (PST) Received: by 10.152.109.204 with HTTP; Fri, 1 Feb 2013 16:29:42 -0800 (PST) In-Reply-To: References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> <-3128426172162859719@unknownmsgid> <022b01ce0085$a4452b90$eccf82b0$@tavis.ca> <6D2125B5-02DE-4016-86BA-38F8FA100DB4@nordsc.com> <3F268583-BC18-412F-8348-16AFB070EC21@nordsc.com> <694EDD73-FAB5-419E-B72D-717F5F7F21BF@nordsc.com> <7338D97E-0362-486B-AAF1-F9CD64813213@nordsc.com> <4522B945ABF34A74A39FCE1A0C68A9D2@gmail.com> <680DF765108749568E54174961CF84C6@gmail.com> Date: Fri, 1 Feb 2013 19:29:42 -0500 Message-ID: Subject: Re: NEW RELATION: action From: Darrel Miller To: mike amundsen Content-Type: multipart/alternative; boundary=e89a8f234705bf929f04d4b2f462 Cc: Ioseb Dzmanashvili , link-relations X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: darrel@tavis.ca List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2013 00:29:44 -0000 --e89a8f234705bf929f04d4b2f462 Content-Type: text/plain; charset=ISO-8859-1 Mike, On Fri, Feb 1, 2013 at 6:46 PM, mike amundsen wrote: > Darrel: > > did you just make a case for the abiltiy to do unsafe non-idempotent empty > requests in OData and HAL w/o using this new rel value? > > > For sure. We can mint rel="print", rel="start", rel="stop", rel="restart", rel="launch", rel="publish", rel="submit", rel ="poke", rel="like", rel="+1" and in our client code we can do if (userClickedAButton and rel in ("print", "start", "stop", "restart", "launch", "publish", "submit", "poke", "like") { httpClient.Post(targetUrl, null) } Tongue planted firmly in cheek Darrel --e89a8f234705bf929f04d4b2f462 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Mike,


On Fri, Feb 1, 2013 at 6:46 PM, mike amundsen <mamund@yahoo.co= m> wrote:
Darrel:

did you just make a case for th= e abiltiy to do unsafe non-idempotent empty requests in OData and HAL w/o u= sing this new rel value?



For sure. =A0We can mint rel=3D"print&= quot;, rel=3D"start", rel=3D"stop", rel=3D"restart= ", rel=3D"launch", rel=3D"publish", rel=3D"su= bmit", rel =3D"poke", rel=3D"like", rel=3D"+1= "

and in our client code we can do

if (userClickedAButton and rel in ("print&q= uot;, "start", "stop", "restart", "launc= h", "publish", "submit", "poke", "l= ike") {

=A0 =A0httpClient.Post(targetUrl, null)

}
=A0
<curre= ntState>Tongue planted firmly in cheek</currentState>

Darrel

--e89a8f234705bf929f04d4b2f462-- From mca@amundsen.com Fri Feb 1 17:11:31 2013 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 ECBA421E805A for ; Fri, 1 Feb 2013 17:11:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.521 X-Spam-Level: X-Spam-Status: No, score=0.521 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FORGED_YAHOO_RCVD=2.297, HTML_MESSAGE=0.001, J_CHICKENPOX_38=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 9Vhw2988O7O1 for ; Fri, 1 Feb 2013 17:11:25 -0800 (PST) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by ietfa.amsl.com (Postfix) with ESMTP id C170C21E8049 for ; Fri, 1 Feb 2013 17:11:24 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id c10so1218239wiw.2 for ; Fri, 01 Feb 2013 17:11:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :x-gm-message-state; bh=DyzMnEedC8bmeLdaWD1IFH34XNt2YpP1evNEwR0npDw=; b=J11NM+Bbj8XltdO4oZdusCHQ/OQvKw48rx/CHQVvvhp1TlNJg+pNEBdt5nBRKm14XV q7Ut+r23Aan2yD0ClSfy1tLT9PftB95DbHDeNe3vQEzRbxK2BUnZ8jlKCbo/KTClGPwt WP3HbBNMacZL8JcTSeJk20FnXnojf1XkMlaSEfq0MA3K7nJ8KT4D7kKceGvkrssNyP09 UWdYq9oNs2M02rS97aO8ouMmWMzmf18hnZbucwWAZ86llmzaMQuaC8udD5CQcyZEieJN aDp0AsFDHWE+r3Z3Ngf67zfxB7Lw6Gf+dweYoereVD/VuqpxyNqE9f+bjEMU5V5D3LO7 +8FA== X-Received: by 10.180.82.65 with SMTP id g1mr730815wiy.22.1359767483899; Fri, 01 Feb 2013 17:11:23 -0800 (PST) MIME-Version: 1.0 Sender: mca@amundsen.com Received: by 10.194.243.129 with HTTP; Fri, 1 Feb 2013 17:11:02 -0800 (PST) In-Reply-To: References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> <-3128426172162859719@unknownmsgid> <022b01ce0085$a4452b90$eccf82b0$@tavis.ca> <6D2125B5-02DE-4016-86BA-38F8FA100DB4@nordsc.com> <3F268583-BC18-412F-8348-16AFB070EC21@nordsc.com> <694EDD73-FAB5-419E-B72D-717F5F7F21BF@nordsc.com> <7338D97E-0362-486B-AAF1-F9CD64813213@nordsc.com> <4522B945ABF34A74A39FCE1A0C68A9D2@gmail.com> <680DF765108749568E54174961CF84C6@gmail.com> From: mike amundsen Date: Fri, 1 Feb 2013 20:11:02 -0500 X-Google-Sender-Auth: o_1GKAavlVkj1MZ0vGVT2oe0fcA Message-ID: Subject: Re: NEW RELATION: action To: darrel@tavis.ca Content-Type: multipart/alternative; boundary=f46d0442832cdadfd804d4b3896e X-Gm-Message-State: ALoCoQmz8DjkY4UPW7a/M1E0xORDND8ifY7guY1FTf9KZb9ODIOYOOWKI2ySGlI2D1ObXrtji4Vy Cc: Ioseb Dzmanashvili , link-relations 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: Sat, 02 Feb 2013 01:11:32 -0000 --f46d0442832cdadfd804d4b3896e Content-Type: text/plain; charset=ISO-8859-1 Well, I've taken a couple passes at working to expose the unique value of this proposed link rel value and haven't found it. At this point, my Qs have come full circle. For me, what you describe remains a narrowly-focused use case which I rarely encounter (generic description of empty POST) and when I do encounter the need, I find I have more than enough options already available to me. You guys are welcome to it. Cheers. mamund +1.859.757.1449 skype: mca.amundsen http://amundsen.com/blog/ http://twitter.com/mamund https://github.com/mamund http://www.linkedin.com/in/mikeamundsen On Fri, Feb 1, 2013 at 7:29 PM, Darrel Miller wrote: > Mike, > > > On Fri, Feb 1, 2013 at 6:46 PM, mike amundsen wrote: > >> Darrel: >> >> did you just make a case for the abiltiy to do unsafe non-idempotent >> empty requests in OData and HAL w/o using this new rel value? >> >> >> > For sure. We can mint rel="print", rel="start", rel="stop", > rel="restart", rel="launch", rel="publish", rel="submit", rel ="poke", > rel="like", rel="+1" > > and in our client code we can do > > if (userClickedAButton and rel in ("print", "start", "stop", "restart", > "launch", "publish", "submit", "poke", "like") { > > httpClient.Post(targetUrl, null) > > } > > Tongue planted firmly in cheek > > Darrel > > --f46d0442832cdadfd804d4b3896e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Well, I've taken a couple passes at=A0working=A0to expose the unique va= lue of this proposed link rel value and haven't found it. At this point= , my Qs have come full circle.

For me, what you describe= remains a narrowly-focused use case which I rarely encounter (generic desc= ription of empty POST) and when I do=A0encounter=A0the need, I find I have = more than enough options already available to me.

You guys are welcome to it.

Ch= eers.



On Fri, Feb 1, 2013 at 7:29 PM, Darrel M= iller <darrel.miller@gmail.com> wrote:
Mike,


On Fri, Feb 1, 2013 at 6:46 PM, mike amundse= n <mamund@yahoo.com> wrote:
Darrel:

did you just make a case for th= e abiltiy to do unsafe non-idempotent empty requests in OData and HAL w/o u= sing this new rel value?


For sure. =A0We can mint rel=3D"print", rel=3D= "start", rel=3D"stop", rel=3D"restart", rel= =3D"launch", rel=3D"publish", rel=3D"submit",= rel =3D"poke", rel=3D"like", rel=3D"+1"

and in our client code we can do

if (userClickedAButton and rel in ("print", "start",= "stop", "restart", "launch", "publish&q= uot;, "submit", "poke", "like") {

=A0 =A0httpClient.Post(targetUrl, null)

<= /div>
}
=A0
<currentState>Tongue planted firm= ly in cheek</currentState>

Darrel


--f46d0442832cdadfd804d4b3896e-- From jan.algermissen@nordsc.com Fri Feb 1 22:27:05 2013 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 5D72D21F9114 for ; Fri, 1 Feb 2013 22:27:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.100, 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 jV65ih6OZvAM for ; Fri, 1 Feb 2013 22:27:05 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by ietfa.amsl.com (Postfix) with ESMTP id AD6D421F8F20 for ; Fri, 1 Feb 2013 22:27:03 -0800 (PST) Received: from [192.168.2.103] (p548FD3BC.dip.t-dialin.net [84.143.211.188]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0MAyoK-1U9C3r1qp2-00AbiK; Sat, 02 Feb 2013 07:26:59 +0100 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: NEW RELATION: action From: Jan Algermissen In-Reply-To: Date: Sat, 2 Feb 2013 07:26:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> <-3128426172162859719@unknownmsgid> <022b01ce0085$a4452b90$eccf82b0$@tavis.ca> <6D2125B5-02DE-4016-86BA-38F8FA100DB4@nordsc.com> <3F268583-BC18-412F-8348-16AFB070EC21@nordsc.com> <694EDD73-FAB5-419E-B72D-717F5F7F21BF@nordsc.com> <7338D97E-0362-486B-AAF1-F9CD64813213@nordsc.com> <4522B945ABF34A74A39FCE1A0C68A9D2@gmail.com> <680DF765108749568E54174961CF84C6@gmail.com> To: darrel@tavis.ca X-Mailer: Apple Mail (2.1499) X-Provags-ID: V02:K0:QakRQ86tRsokLsWzPDXpMMa5TQewr8quOqarjqhsXEz 1nr6Oy1saZqDbALcL1m/8DQF0g6ycrCGTg5qRADbpIH3yRPlq9 hZFkbrfOIX1xwXEGY3/99PiXacUDVduNo4skmTyBS61MM+1gzX Az8P1Am92+d+QG7KpT07BX7kXaGgBt6Y3bNW4PCbKsMoWXZiVd c4Tn0Lpbs/ma4c9Sfa6ChD5X4z0i30ElGuvYz+QrFJU6KSjEM8 xFLtLKw/nkYN8Sjo5T6BbJdKFSv2Hw8Ap5UXaHf2zbdqzbWhop 9DuHsKvQkr0hqZjt+4NocXvqSX9QzhVbMLXwHVwCobuLnjpS64 5IO9UUfgGdxxLJelDKeXheMW64dnwhffAQ/2/5ZHrUxjfTBXz/ ISnEHA1B2MOVg== Cc: link-relations , 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: Sat, 02 Feb 2013 06:27:05 -0000 On 02.02.2013, at 01:29, Darrel Miller wrote: >=20 >=20 > For sure. We can mint rel=3D"print", rel=3D"start", rel=3D"stop", = rel=3D"restart", rel=3D"launch", rel=3D"publish", rel=3D"submit", rel = =3D"poke", rel=3D"like", rel=3D"+1" >=20 What happened to the idea that REST means 'representational state = transfer' and not 'remote method invocation'? Jan= From ioseb.dzmanashvili@gmail.com Sat Feb 2 03:40:35 2013 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 8DF2421F906C for ; Sat, 2 Feb 2013 03:40:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_38=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 Z-TNKtMDpwnp for ; Sat, 2 Feb 2013 03:40:34 -0800 (PST) Received: from mail-ea0-f178.google.com (mail-ea0-f178.google.com [209.85.215.178]) by ietfa.amsl.com (Postfix) with ESMTP id 4071B21F9050 for ; Sat, 2 Feb 2013 03:40:34 -0800 (PST) Received: by mail-ea0-f178.google.com with SMTP id a14so2147080eaa.23 for ; Sat, 02 Feb 2013 03:40:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:message-id:in-reply-to:references :subject:x-mailer:mime-version:content-type; bh=wxUoHJJtPRhEvk6R9G7s8wI4f7lyj9B5Yk9w5LL7x3Y=; b=KNKrjtOXPO4dHpV5Sr059fiS05DNb8EA6YyYkmRJ8vDkOKTvV+dU8W/KQhr9ipv2QQ e6/VAJwscFtqaegeKo76WOvfKzIbH7HEUA6zyVVg+mWxhoSvfEvQgV4RbTeeSh/uu188 Hd/6oaGpEP5lEp0pqukJyVkX+dQR2hoZCGHXqhY6e8ToMv6ZJk99LP4GMsf676ETDjEV qBRK32fP2GDLH4s7KbpzcU3uGuG5fZnsW8rd/jViyYwKBr3Zz0VxZgDRe3PiUeYe5OWK PttxFV9MQ9vfCUr/rE3E0R3H2gzyn9QVRi3u7g+aN04EBQuvkdTcJY4CCANqJmZe051D nwnA== X-Received: by 10.14.177.1 with SMTP id c1mr50568081eem.8.1359805233387; Sat, 02 Feb 2013 03:40:33 -0800 (PST) Received: from [192.168.1.3] ([176.73.174.236]) by mx.google.com with ESMTPS id t44sm17156475eeo.2.2013.02.02.03.40.31 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 02 Feb 2013 03:40:32 -0800 (PST) Date: Sat, 2 Feb 2013 15:40:30 +0400 From: Ioseb Dzmanashvili To: mike amundsen Message-ID: <94771E9278544A86AAB5A1AFB34636EA@gmail.com> In-Reply-To: References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> <-3128426172162859719@unknownmsgid> <022b01ce0085$a4452b90$eccf82b0$@tavis.ca> <6D2125B5-02DE-4016-86BA-38F8FA100DB4@nordsc.com> <3F268583-BC18-412F-8348-16AFB070EC21@nordsc.com> <694EDD73-FAB5-419E-B72D-717F5F7F21BF@nordsc.com> <7338D97E-0362-486B-AAF1-F9CD64813213@nordsc.com> <4522B945ABF34A74A39FCE1A0C68A9D2@gmail.com> <680DF765108749568E54174961CF84C6@gmail.com> Subject: Re: NEW RELATION: action X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="510cfb2e_5649da4d_28a" Cc: darrel@tavis.ca, link-relations 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: Sat, 02 Feb 2013 11:40:35 -0000 --510cfb2e_5649da4d_28a Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Thank you very much Mike! ioseb On Saturday, February 2, 2013 at 5:11 AM, mike amundsen wrote: > Well, I've taken a couple passes at working to expose the unique value of this proposed link rel value and haven't found it. At this point, my Qs have come full circle. > > For me, what you describe remains a narrowly-focused use case which I rarely encounter (generic description of empty POST) and when I do encounter the need, I find I have more than enough options already available to me. > > You guys are welcome to it. > > Cheers. > > mamund > +1.859.757.1449 > skype: mca.amundsen > http://amundsen.com/blog/ > http://twitter.com/mamund > https://github.com/mamund > http://www.linkedin.com/in/mikeamundsen > > On Fri, Feb 1, 2013 at 7:29 PM, Darrel Miller wrote: > > Mike, > > > > > > On Fri, Feb 1, 2013 at 6:46 PM, mike amundsen wrote: > > > Darrel: > > > > > > did you just make a case for the abiltiy to do unsafe non-idempotent empty requests in OData and HAL w/o using this new rel value? > > > > > > > > > > For sure. We can mint rel="print", rel="start", rel="stop", rel="restart", rel="launch", rel="publish", rel="submit", rel ="poke", rel="like", rel="+1" > > > > and in our client code we can do > > > > if (userClickedAButton and rel in ("print", "start", "stop", "restart", "launch", "publish", "submit", "poke", "like") { > > > > httpClient.Post(targetUrl, null) > > > > } > > > > Tongue planted firmly in cheek > > > > Darrel > > > --510cfb2e_5649da4d_28a Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Thank you very much Mike=21

ioseb
=20

On Saturday, =46ebruar= y 2, 2013 at 5:11 AM, mike amundsen wrote:

Well, I've taken a couple passes at&n= bsp;working to expose the unique value of this proposed link rel val= ue and haven't found it. At this point, my Qs have come full circle.
=
=46or me, what you describe remains a narrowly-focused use= case which I rarely encounter (generic description of empty POST) and wh= en I do encounter the need, I find I have more than enough opti= ons already available to me.

You guys are welcome to it.

= Cheers.



On =46ri, =46eb 1, 2013 at 7:29 PM, Darrel Miller <darrel.miller=40gmail.com> wrote:
Mike,


On =46ri, =46eb 1, 2= 013 at 6:46 PM, mike amundsen <mamund=40yahoo.com&g= t; wrote:
Darrel:

did you just make a case for the abiltiy to do unsafe non-idempo= tent empty requests in OData and HAL w/o using this new rel value=3F



=46or sure.  We can mint rel=3D=22pri= nt=22, rel=3D=22start=22, rel=3D=22stop=22, rel=3D=22restart=22, rel=3D=22= launch=22, rel=3D=22publish=22, rel=3D=22submit=22, rel =3D=22poke=22, re= l=3D=22like=22, rel=3D=22+1=22

and in our client code we can do

=
if (userClickedAButton and rel in (=22print=22, =22start=22, =22stop= =22, =22restart=22, =22launch=22, =22publish=22, =22submit=22, =22poke=22= , =22like=22) =7B

   httpClient.Post(targetUrl, null)

=7D
 
<currentState>Tong= ue planted firmly in cheek</currentState>

Darrel


=20 =20 =20 =20 =20

--510cfb2e_5649da4d_28a-- From ioseb.dzmanashvili@gmail.com Sat Feb 2 03:57:02 2013 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 9877721F908A for ; Sat, 2 Feb 2013 03:57:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.467, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=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 oTSrabgTy0hK for ; Sat, 2 Feb 2013 03:57:02 -0800 (PST) Received: from mail-ea0-f174.google.com (mail-ea0-f174.google.com [209.85.215.174]) by ietfa.amsl.com (Postfix) with ESMTP id 9018621F9085 for ; Sat, 2 Feb 2013 03:57:01 -0800 (PST) Received: by mail-ea0-f174.google.com with SMTP id 1so2102576eaa.19 for ; Sat, 02 Feb 2013 03:57:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:message-id:in-reply-to:references :subject:x-mailer:mime-version:content-type; bh=tGLemxsuN9cKzB+bR2w4P0lvn4pimhzg4xkYkHR61xM=; b=TtJjt0JgB0KAcCaIF5YHpv1yCcZoTiLd3yao3cwyqnNYqk237CtXnFb15JBDTnBU+/ CvSDGM6DHFA/vCm/OV3XpPwFqYmRNFeP6F7zIPV1EjxVl2yuXBLm05FrLHNzrCg6xJfZ Ou789o86A+OH+pHKA195xSQsMc/ZBN42w6xGr4AXJTHpc3OJ4I49xcPGWI0lpALkCTtj fVnQKGHeRGp43oQfdtwZzWRX+bc3lKodlQQwV5uR9NrDDWJLUQMDB2RXRanavC8ekV+C 244cxWgBvngUk5uoY2RKgRxe0kdePMWZNcQ41amUxyzXsRq2MY6lgWLGlolcw6frGFZI /p5A== X-Received: by 10.14.210.132 with SMTP id u4mr49319625eeo.19.1359806220690; Sat, 02 Feb 2013 03:57:00 -0800 (PST) Received: from [192.168.1.3] ([176.73.174.236]) by mx.google.com with ESMTPS id 3sm17206235eej.6.2013.02.02.03.56.58 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 02 Feb 2013 03:56:59 -0800 (PST) Date: Sat, 2 Feb 2013 15:56:58 +0400 From: Ioseb Dzmanashvili To: Jan Algermissen Message-ID: <60C776A1F60A44899807B711C5773017@gmail.com> In-Reply-To: References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> <-3128426172162859719@unknownmsgid> <022b01ce0085$a4452b90$eccf82b0$@tavis.ca> <6D2125B5-02DE-4016-86BA-38F8FA100DB4@nordsc.com> <3F268583-BC18-412F-8348-16AFB070EC21@nordsc.com> <694EDD73-FAB5-419E-B72D-717F5F7F21BF@nordsc.com> <7338D97E-0362-486B-AAF1-F9CD64813213@nordsc.com> <4522B945ABF34A74A39FCE1A0C68A9D2@gmail.com> <680DF765108749568E54174961CF84C6@gmail.com> Subject: Re: NEW RELATION: action X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="510cff0a_2645da6e_28a" Cc: darrel@tavis.ca, link-relations 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: Sat, 02 Feb 2013 11:57:02 -0000 --510cff0a_2645da6e_28a Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Jan, > What happened to the idea that REST means 'representational state transfer' and not 'remote method invocation'? Sorry for not giving up on this, but i've few questions. I do not want to dive into REST details, but from REST description, representation is a sequence of bytes + meta data. From both, REST and HTTP PoV i do not see(or maybe do not understand?) why "Representaiontal" part of the style is violated? This is the quote from Fielding's dissertation: > What makes HTTP significantly different from RPC is that the requests are directed to resources using a generic interface with standard semantics that can be interpreted by intermediaries almost as well as by the machines that originate services What do we violate here? is there any restriction which prevents us from defining processing resources? cheers, ioseb On Saturday, February 2, 2013 at 10:26 AM, Jan Algermissen wrote: > > On 02.02.2013, at 01:29, Darrel Miller wrote: > > > > > > > For sure. We can mint rel="print", rel="start", rel="stop", rel="restart", rel="launch", rel="publish", rel="submit", rel ="poke", rel="like", rel="+1" > > What happened to the idea that REST means 'representational state transfer' and not 'remote method invocation'? > > > Jan --510cff0a_2645da6e_28a Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Jan,

> What happ= ened to the idea that REST means 'representational state transfer' and no= t 'remote method invocation'=3F

Sorry for not gi= ving up on this, but i've few questions. I do not want to dive into REST = details, but from REST description, representation is a sequence of bytes= + meta data. =46rom both, REST and HTTP PoV i do not see(or maybe do not= understand=3F) why =22Representaiontal=22 part of the style is violated=3F=  

This is the quote from =46ielding's disse= rtation:
What makes HT= TP significantly different from RPC is that the requests are directed to = resources using a generic interface with standard semantics that can be i= nterpreted by intermediaries almost as well as by the machines that origi= nate services

What do we violate here=3F is there a= ny restriction which prevents us from defining processing resources=3F

cheers,
ioseb

On Satu= rday, =46ebruary 2, 2013 at 10:26 AM, Jan Algermissen wrote:


On 02.02.2013, at= 01:29, Darrel Miller <darrel.miller=40gmail.com> wrote:



=46or sure. W= e can mint rel=3D=22print=22, rel=3D=22start=22, rel=3D=22stop=22, rel=3D= =22restart=22, rel=3D=22launch=22, rel=3D=22publish=22, rel=3D=22submit=22= , rel =3D=22poke=22, rel=3D=22like=22, rel=3D=22+1=22

What happened to the idea that REST means 'repre= sentational state transfer' and not 'remote method invocation'=3F


Jan
 =20 =20 =20 =20
=20

--510cff0a_2645da6e_28a-- From jan.algermissen@nordsc.com Sat Feb 2 05:50:57 2013 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 509F321F8895 for ; Sat, 2 Feb 2013 05:50:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.863 X-Spam-Level: X-Spam-Status: No, score=-1.863 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_32=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 IKh-6+0opLsM for ; Sat, 2 Feb 2013 05:50:56 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by ietfa.amsl.com (Postfix) with ESMTP id 9591521F8799 for ; Sat, 2 Feb 2013 05:50:56 -0800 (PST) Received: from [192.168.2.103] (p548FD3BC.dip.t-dialin.net [84.143.211.188]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0Lm4GH-1Uah813HcX-00ZdZA; Sat, 02 Feb 2013 14:50:53 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: NEW RELATION: action From: Jan Algermissen In-Reply-To: <60C776A1F60A44899807B711C5773017@gmail.com> Date: Sat, 2 Feb 2013 14:50:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> <-3128426172162859719@unknownmsgid> <022b01ce0085$a4452b90$eccf82b0$@tavis.ca> <6D2125B5-02DE-4016-86BA-38F8FA100DB4@nordsc.com> <3F268583-BC18-412F-8348-16AFB070EC21@nordsc.com> <694EDD73-FAB5-419E-B72D-717F5F7F21BF@nordsc.com> <7338D97E-0362-486B-AAF1-F9CD64813213@nordsc.com> <4522B945ABF34A74A39FCE1A0C68A9D2@gmail.com> <680DF765108749568E54174961CF84C6@gmail.com> <60C776A1F60A44899807B711C5773017@gmail.com> To: Ioseb Dzmanashvili X-Mailer: Apple Mail (2.1499) X-Provags-ID: V02:K0:eXVNXzG6ma+Fh1/vTqJzdjl+TrwF9/iFFKvHdN73CYA veoQJ+5eXLyhgupwii286JWhbUxrf7nfbD8RS3ftRwcl/q4VtV dvrlTdgMZ2Tpct/AedDmpspqpZaTR4UZNEuREZlIPd9f+M0NLt pJUZpoT6ihniedn3moSjIZ562GEigIYxWHJUSDfAJl+m6x+B4e zEPmn4D91aoX3rvgxsp7Q1/5vccUuhlJzwV6ymgQEoxKFiwwUZ 52BM38l9FsNDiBM7VQYxNwweao8jMh9pDHPIG9AkrfvbeOjwOJ N0DduSqoBZT1hbMwgUMUwoaWauX0paJ9D8XhQ4A9lNw0LLSi8V 23Q82YOiV5DbrzJavozsWvjblEe3+/7hwAXKyEyRalVj3rmVgN fjDNTGyXhb+fg== Cc: darrel@tavis.ca, link-relations 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: Sat, 02 Feb 2013 13:50:57 -0000 On 02.02.2013, at 12:56, Ioseb Dzmanashvili = wrote: > Hi Jan, >=20 > > What happened to the idea that REST means 'representational state = transfer' and not 'remote method invocation'? >=20 > Sorry for not giving up on this, but i've few questions. I do not want = to dive into REST details, but from REST description, representation is = a sequence of bytes + meta data. =46rom both, REST and HTTP PoV i do not = see(or maybe do not understand?) why "Representaiontal" part of the = style is violated?=20 You are not transferring state to advance the application, you are = effectively invoking a non-uniform method (e.g. 'publish') You are not even doing a POST in the sense 'take this data and do with = it as you please'. And for some of your desired cases you are even loosing the visibility a = use of PUT would give you. It's effectively RPC, IMHO. Jan >=20 > This is the quote from Fielding's dissertation: >> What makes HTTP significantly different from RPC is that the requests = are directed to resources using a generic interface with standard = semantics that can be interpreted by intermediaries almost as well as by = the machines that originate services > What do we violate here? is there any restriction which prevents us = from defining processing resources? >=20 > cheers, > ioseb >=20 > On Saturday, February 2, 2013 at 10:26 AM, Jan Algermissen wrote: >=20 >>=20 >> On 02.02.2013, at 01:29, Darrel Miller = wrote: >>=20 >>>=20 >>>=20 >>> For sure. We can mint rel=3D"print", rel=3D"start", rel=3D"stop", = rel=3D"restart", rel=3D"launch", rel=3D"publish", rel=3D"submit", rel = =3D"poke", rel=3D"like", rel=3D"+1" >>=20 >> What happened to the idea that REST means 'representational state = transfer' and not 'remote method invocation'? >>=20 >>=20 >> Jan >=20 From darrel.miller@gmail.com Sat Feb 2 09:54:54 2013 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 0882421F85D9 for ; Sat, 2 Feb 2013 09:54:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, NO_RELAYS=-0.001] 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 G0Y2CecZt+go for ; Sat, 2 Feb 2013 09:54:52 -0800 (PST) Received: from mail-la0-x22c.google.com (la-in-x022c.1e100.net [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC1C21F85C2 for ; Sat, 2 Feb 2013 09:54:52 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id eb20so3598676lab.3 for ; Sat, 02 Feb 2013 09:54:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=XzFDZENn8oIxE9CpM5pX5hkw3opQHeKXbNKpVxXbBGw=; b=0UPKtR2i3Y+mTV66LPzIs+hBbtjfDWeHm1ACdduYLZUn/QwMWDrO+NTwS/VJB4+8sn eR4F8IhqQmYE0QtC17jilYSuDUJwlytjlWdzSaWBr8ejkkf8EX+hwQhnw2edNt7VcJf+ 1yQAnlutTB9Jfg2HX0sQcbBC7lMXZDLHYtSb1WheXrTW/plxr054BfnBVVxRo87nwuyN 5Cq6xCNJ0he3a7zxiqtOhNw9ovIZzVBiNGlG9lby4qkyzHfujXiSNBkKeOFkshLtwpZQ 9zxHd1lqU+e5wnklDjcqWOX6tmE1uAfwFfyUaVOtTgAqeT2kMZG2ieBNkSl5UHJe5nAz FmIA== MIME-Version: 1.0 X-Received: by 10.112.44.161 with SMTP id f1mr6126102lbm.29.1359827691163; Sat, 02 Feb 2013 09:54:51 -0800 (PST) Received: by 10.152.109.204 with HTTP; Sat, 2 Feb 2013 09:54:50 -0800 (PST) In-Reply-To: References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> <-3128426172162859719@unknownmsgid> <022b01ce0085$a4452b90$eccf82b0$@tavis.ca> <6D2125B5-02DE-4016-86BA-38F8FA100DB4@nordsc.com> <3F268583-BC18-412F-8348-16AFB070EC21@nordsc.com> <694EDD73-FAB5-419E-B72D-717F5F7F21BF@nordsc.com> <7338D97E-0362-486B-AAF1-F9CD64813213@nordsc.com> <4522B945ABF34A74A39FCE1A0C68A9D2@gmail.com> <680DF765108749568E54174961CF84C6@gmail.com> <60C776A1F60A44899807B711C5773017@gmail.com> Date: Sat, 2 Feb 2013 12:54:50 -0500 Message-ID: Subject: Re: NEW RELATION: action From: Darrel Miller To: Jan Algermissen Content-Type: multipart/alternative; boundary=bcaec554d1fe7cd20204d4c18e62 Cc: link-relations , Ioseb Dzmanashvili X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: darrel@tavis.ca List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2013 17:54:54 -0000 --bcaec554d1fe7cd20204d4c18e62 Content-Type: text/plain; charset=ISO-8859-1 How about we work with a pseudo real example. I'm building a home automation system. I have various devices that I want to write clients for that will allow me to interact with "resources" in my home. After several link traversals from the the API root I end up doing one of these requests depending on the client device. > GET /home/livingroom/lights/northcorner > Accept: application/hal+xml < 200 OK < Content-Type: application/hal+xml North Corner Living Room Recessed Pot Light Par20 2012-01-07 On > GET /home/livingroom/lights/northcorner > Accept: text/plain < 200 OK < Content-Type: text/plain North Corner light in living room Recessed Pot Light using Par20 bulb Bulb last changed 2012-01-07 Currently On. > GET /home/livingroom/lights/northcorner > Accept: text/plain < 200 OK < Content-Type: text/html

North Corner light in living room

Recessed Pot Light using Par20 bulb

Bulb last changed 2012-01-07

Currently On.

Using either a an embedded link (hal), a link header (plain/text), or an empty form with POST method I can easily augment these representations to make it simple for a client to present the user with an option to change the state of the light using no other knowledge than how to make a POST request. Can you explain to me how these clients would be able to achieve this with PUT? Darrel On Sat, Feb 2, 2013 at 8:50 AM, Jan Algermissen wrote: > > On 02.02.2013, at 12:56, Ioseb Dzmanashvili > wrote: > > > Hi Jan, > > > > > What happened to the idea that REST means 'representational state > transfer' and not 'remote method invocation'? > > > > Sorry for not giving up on this, but i've few questions. I do not want > to dive into REST details, but from REST description, representation is a > sequence of bytes + meta data. From both, REST and HTTP PoV i do not see(or > maybe do not understand?) why "Representaiontal" part of the style is > violated? > > You are not transferring state to advance the application, you are > effectively invoking a non-uniform method (e.g. 'publish') > > You are not even doing a POST in the sense 'take this data and do with it > as you please'. > > And for some of your desired cases you are even loosing the visibility a > use of PUT would give you. It's effectively RPC, IMHO. > > Jan > > > > > > This is the quote from Fielding's dissertation: > >> What makes HTTP significantly different from RPC is that the requests > are directed to resources using a generic interface with standard semantics > that can be interpreted by intermediaries almost as well as by the machines > that originate services > > What do we violate here? is there any restriction which prevents us from > defining processing resources? > > > > cheers, > > ioseb > > > > On Saturday, February 2, 2013 at 10:26 AM, Jan Algermissen wrote: > > > >> > >> On 02.02.2013, at 01:29, Darrel Miller wrote: > >> > >>> > >>> > >>> For sure. We can mint rel="print", rel="start", rel="stop", > rel="restart", rel="launch", rel="publish", rel="submit", rel ="poke", > rel="like", rel="+1" > >> > >> What happened to the idea that REST means 'representational state > transfer' and not 'remote method invocation'? > >> > >> > >> Jan > > > > _______________________________________________ > link-relations mailing list > link-relations@ietf.org > https://www.ietf.org/mailman/listinfo/link-relations > --bcaec554d1fe7cd20204d4c18e62 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
How about we work with a pseudo real example. =A0I'm b= uilding a home automation system. =A0I have various devices that I want to = write clients for that will allow me to interact with "resources"= in my home.

After several link traversals from the the API root I = end up doing one of these requests depending on the client device.

> GET /home/livingroom/lights/northcorner
> Accept: =A0application/hal+xml

< 200 OK
< Content-Type: application/hal+xml=

<resource href=3D"/home/livin= groom/lights/northcorner">
=A0 =A0<name>North Corner</name>
=A0= =A0<room>Living Room</room>
=A0 =A0<lig= htStyle>Recessed Pot Light</lightStyle>
=A0 =A0<= ;bulbType>Par20</bulbType>
=A0 =A0<lastChanged>2012-01-07</lastChanged>
=A0 =A0<currentState>On</currentState>
</resource>


> GET /home/livingroom/lights/northcorner
> Accept: = =A0text/plain

< 200 OK
< Content-T= ype: text/plain

North Corner light in living room<= br>
Recessed Pot Light using Par20 bulb
Bulb l= ast changed 2012-01-07
Currently On.


> GET /home/livingroom/lights/n= orthcorner
> Accept: =A0text/plain

< 200 OK
<= div>< Content-Type: text/html
<html>
<body>
<p>North Corner light in living room</p&= gt;
<p>Recessed Pot Light using Par20 bulb</p>
<p>Bulb last changed 2012-01-07</p>
<p>Current= ly On.</p>
</body>
</html>= ;


Using eith= er a an embedded link (hal), a link header (plain/text), =A0or an empty for= m with POST method I can easily augment these representations to make it si= mple for a client to present the user with an option to change the state of= the light using no other knowledge than how to make a POST request.

Can you explain to me how these clients wou= ld be able to achieve this with PUT?

<= br>
Darrel




On Sat,= Feb 2, 2013 at 8:50 AM, Jan Algermissen <jan.algermissen@nordsc.= com> wrote:

On 02.02.2013, at 12:56, Ioseb Dzmanashvili <ioseb.dzmanashvili@gmail.com> wrote:

> Hi Jan,
>
> > What happened to the idea that REST means 'representational s= tate transfer' and not 'remote method invocation'?
>
> Sorry for not giving up on this, but i've few questions. I do not = want to dive into REST details, but from REST description, representation i= s a sequence of bytes + meta data. From both, REST and HTTP PoV i do not se= e(or maybe do not understand?) why "Representaiontal" part of the= style is violated?

You are not transferring state to advance the application, you are ef= fectively invoking a non-uniform method (e.g. 'publish')

You are not even doing a POST in the sense 'take this data and do with = it as you please'.

And for some of your desired cases you are even loosing the visibility a us= e of PUT would give you. It's effectively RPC, IMHO.

Jan


>
> This is the quote from Fielding's dissertation:
>> What makes HTTP significantly different from RPC is that the reque= sts are directed to resources using a generic interface with standard seman= tics that can be interpreted by intermediaries almost as well as by the mac= hines that originate services
> What do we violate here? is there any restriction which prevents us fr= om defining processing resources?
>
> cheers,
> ioseb
>
> On Saturday, February 2, 2013 at 10:26 AM, Jan Algermissen wrote:
>
>>
>> On 02.02.2013, at 01:29, Darrel Miller <darrel.miller@gmail.com> wrote:
>>
>>>
>>>
>>> For sure. We can mint rel=3D"print", rel=3D"sta= rt", rel=3D"stop", rel=3D"restart", rel=3D"la= unch", rel=3D"publish", rel=3D"submit", rel =3D&qu= ot;poke", rel=3D"like", rel=3D"+1"
>>
>> What happened to the idea that REST means 'representational st= ate transfer' and not 'remote method invocation'?
>>
>>
>> Jan
>

_____________________________= __________________
link-relations mailing list
link-relations@ietf.org
https://www.ietf.org/mailman/listinfo/link-relations

--bcaec554d1fe7cd20204d4c18e62-- From svartman95@gmail.com Sat Feb 2 11:01:44 2013 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 2B29C21F85B3 for ; Sat, 2 Feb 2013 11:01:44 -0800 (PST) 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 sGhzJpZkA4sI for ; Sat, 2 Feb 2013 11:01:43 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 37BC321F85A4 for ; Sat, 2 Feb 2013 11:01:43 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id n8so5590533lbj.31 for ; Sat, 02 Feb 2013 11:01:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=UvocZD3bQlqgWHHt3rQOCHTs/98D4Rvthr33En3Ez+s=; b=Z/PCA9p2DYvVrDm1vmioV7ihOHy8/SaOmPiv+CBijQgzrZ5o5maE2OAdXh8Vbhftpg Zjqi7qDeAkGyELMOe0RY9mCIr/TYwUpkVLi7JcJ7xOdX8fqEYw8jBMm9QTKuz3+ffSjp qsqdcqMadFUZ1qLMvhIUf09blseyb0LWWSfbvHhWf8OPjLId9t10/DXHQOiaFTWabfRm YrD+oJOzaEZXEXMI1gm3PkxXBorcOONzYUNLhxbMfv0A+kP5vplJ29o5OZQh+AGV20Fd 2G12tTSjdYhYeAkI6+aQYxVNZ1EfMaMOVhzZrzLY7PflDkzDrmkqpsfmj7Il6t1r6K1X 2PaA== MIME-Version: 1.0 X-Received: by 10.112.51.44 with SMTP id h12mr6105546lbo.111.1359831701493; Sat, 02 Feb 2013 11:01:41 -0800 (PST) Received: by 10.152.147.137 with HTTP; Sat, 2 Feb 2013 11:01:41 -0800 (PST) In-Reply-To: References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> <-3128426172162859719@unknownmsgid> <022b01ce0085$a4452b90$eccf82b0$@tavis.ca> <6D2125B5-02DE-4016-86BA-38F8FA100DB4@nordsc.com> <3F268583-BC18-412F-8348-16AFB070EC21@nordsc.com> <694EDD73-FAB5-419E-B72D-717F5F7F21BF@nordsc.com> <7338D97E-0362-486B-AAF1-F9CD64813213@nordsc.com> <4522B945ABF34A74A39FCE1A0C68A9D2@gmail.com> <680DF765108749568E54174961CF84C6@gmail.com> <60C776A1F60A44899807B711C5773017@gmail.com> Date: Sat, 2 Feb 2013 19:01:41 +0000 Message-ID: Subject: Re: NEW RELATION: action From: Bjartur Thorlacius To: darrel@tavis.ca Content-Type: text/plain; charset=UTF-8 Cc: Ioseb Dzmanashvili , link-relations 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: Sat, 02 Feb 2013 19:01:44 -0000 I think the point of the criticism is that either it replaces DELETE /sample HTTP/1.0 with POST /sample?delete HTTP/1.0 that is, uses e.g. the query component, a string of information to be interpreted by the resource, to convey the action and the HTTP method exclusively to convey the characteristics of the action (e.g. idempotence), or worse, depends on context for semantics. The purpose of the proposal is that of the HTTP header Options, plus allowing private or "ad-hoc" methods. Theoretically, separating information about method characteristics is a good thing. But many want this to be done without cluttering identifiers. Although technically, /sample?delete is quite obviously an identifier for the action of deleting /sample. Deriving /sample from the action URI/IRI is trivial to do and already specified in a RFC. But it would be even better do convey the action in a separate HTTP field. From ioseb.dzmanashvili@gmail.com Sun Feb 10 14:31:34 2013 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 855EE21F8806 for ; Sun, 10 Feb 2013 14:31:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.437, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=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 iFKwGN7ClZRl for ; Sun, 10 Feb 2013 14:31:33 -0800 (PST) Received: from mail-ea0-f181.google.com (mail-ea0-f181.google.com [209.85.215.181]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1E821F87F5 for ; Sun, 10 Feb 2013 14:31:33 -0800 (PST) Received: by mail-ea0-f181.google.com with SMTP id i13so2385451eaa.12 for ; Sun, 10 Feb 2013 14:31:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:message-id:in-reply-to:references :subject:x-mailer:mime-version:content-type; bh=B8GFgSbYMdj2Gv+sd5S+HF+jsfub4zxYOf/ZgHoeMhM=; b=ibuZ64TMcTaBrDDRrOvhWS48YKieBhj2dlOF0p1H7uAXM6ldcfZYeMv5b8Qux9lrmF AVHAr0II4xP1s4wJa0q1hCfeeo7/OVVIs1bqll8ZZkIh4nC/ISZHgtuW/0Q9wo3ClM8k xLfqNsh/Wgux5hf0TnFMiRYbSQen4OMTEKkFahRXEvu2NCduzPrXazrq/XBJqMlXWdau BAcaIgTPcD6LZMO4TxTX9Q+bbuLWFYpXgWnW7CvAM6VvOQj4HPE8n1DEkc3P2BP9dNbC HYapgKYicphPheAnkwL9jF/iMLwmDpwSQQulwZifBRoFBC6huhPMovLETCA81rUWRgIb hN2g== X-Received: by 10.14.218.132 with SMTP id k4mr43201184eep.27.1360535492222; Sun, 10 Feb 2013 14:31:32 -0800 (PST) Received: from [192.168.1.5] ([176.73.174.236]) by mx.google.com with ESMTPS id j46sm56067136eeo.3.2013.02.10.14.31.28 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 10 Feb 2013 14:31:30 -0800 (PST) Date: Mon, 11 Feb 2013 02:31:27 +0400 From: Ioseb Dzmanashvili To: Jan Algermissen Message-ID: <824BDB9E220F444F9B3A7B5F257A3361@gmail.com> In-Reply-To: References: <847FE4BC9B1845519A22874F71FE4BD9@gmail.com> <74AC1732-B805-471A-97F4-277E937E1CB2@nordsc.com> <80E75BAFA5C44F9AB296DC5256A22930@gmail.com> <-3128426172162859719@unknownmsgid> <022b01ce0085$a4452b90$eccf82b0$@tavis.ca> <6D2125B5-02DE-4016-86BA-38F8FA100DB4@nordsc.com> <3F268583-BC18-412F-8348-16AFB070EC21@nordsc.com> <694EDD73-FAB5-419E-B72D-717F5F7F21BF@nordsc.com> <7338D97E-0362-486B-AAF1-F9CD64813213@nordsc.com> <4522B945ABF34A74A39FCE1A0C68A9D2@gmail.com> <680DF765108749568E54174961CF84C6@gmail.com> <60C776A1F60A44899807B711C5773017@gmail.com> Subject: Re: NEW RELATION: action X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="51181fbf_706b674e_2d6" Cc: darrel@tavis.ca, link-relations 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: Sun, 10 Feb 2013 22:31:34 -0000 --51181fbf_706b674e_2d6 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Jan, Sorry for delayed response. Here are my answers: > You are not transferring state to advance the application, you are effectively invoking a non-uniform method (e.g. 'publish') > You are not even doing a POST in the sense 'take this data and do with it as you please'. Here is what HTTPBis says: "The actual function performed by the POST method is determined by the server and is usually dependent on the effective request URI." [1] and if i'm not wrong "dependent on the effective request URI" is the key here. As far as sending an "empty" POST requests are not prohibited and function performed is determined by the server and depends on the effective request URI how do we violate uniformity? Below are several quotes from Roy Fielding: "Note that POST, regardless of which meaning is being used, has none of the characteristics that would make it useful for the architecture to know exactly what is going on". [2] In the same post he defines POST method as "append-this" and POST method as "process-this". And says: "POST(a), as "append this", is unsafe, non-idempotent, non-cacheable, operates on an unknown resource, and has only minor visibility since there is no way for an intermediary to anticipate the state of the resource after the append aside from "some state was added". POST(p), as "process this", doesn't even have that minor visibility. Thus, an architectural style like REST can only improve the performance of a POST-based architecture by finding ways to escape POST (e.g., 201)." [2] If POST doesn't have visibility and performed function is dependent on the request URI and no one can know in advance what will be performed: 1) how is it possible to invoke non-uniform method? 2) in what sense it's RPC? 3) and how this is different compared to including same information in the entity body and asking server to do something? > And for some of your desired cases you are even loosing the visibility a use of PUT would give you. It's effectively RPC, IMHO. I do not understand how PUT can help in this case. [1]. http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-21#section-5.3.3 [2]. http://tech.groups.yahoo.com/group/rest-discuss/message/4732?threaded=1&p=5 Best regards, ioseb On Saturday, February 2, 2013 at 5:50 PM, Jan Algermissen wrote: > > On 02.02.2013, at 12:56, Ioseb Dzmanashvili wrote: > > > Hi Jan, > > > > > What happened to the idea that REST means 'representational state transfer' and not 'remote method invocation'? > > > > Sorry for not giving up on this, but i've few questions. I do not want to dive into REST details, but from REST description, representation is a sequence of bytes + meta data. From both, REST and HTTP PoV i do not see(or maybe do not understand?) why "Representaiontal" part of the style is violated? > > You are not transferring state to advance the application, you are effectively invoking a non-uniform method (e.g. 'publish') > > You are not even doing a POST in the sense 'take this data and do with it as you please'. > > And for some of your desired cases you are even loosing the visibility a use of PUT would give you. It's effectively RPC, IMHO. > > Jan > > > > > > This is the quote from Fielding's dissertation: > > > What makes HTTP significantly different from RPC is that the requests are directed to resources using a generic interface with standard semantics that can be interpreted by intermediaries almost as well as by the machines that originate services > > > > What do we violate here? is there any restriction which prevents us from defining processing resources? > > > > cheers, > > ioseb > > > > On Saturday, February 2, 2013 at 10:26 AM, Jan Algermissen wrote: > > > > > > > > On 02.02.2013, at 01:29, Darrel Miller wrote: > > > > > > > > > > > > > > > For sure. We can mint rel="print", rel="start", rel="stop", rel="restart", rel="launch", rel="publish", rel="submit", rel ="poke", rel="like", rel="+1" > > > > > > What happened to the idea that REST means 'representational state transfer' and not 'remote method invocation'? > > > > > > > > > Jan --51181fbf_706b674e_2d6 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Jan,

Sorry for dela= yed response. Here are my answers:

> You are = not transferring state to advance the application, you are effectively in= voking a non-uniform method (e.g. 'publish')
> You are not e= ven doing a POST in the sense 'take this data and do with it as you pleas= e'.

Here is what HTTPBis says: =22The actual fun= ction performed by the POST method is determined by the server and is usu= ally dependent on the effective request URI.=22 =5B1=5D

and if i'm not wrong =22dependent on the effective request URI=22= is the key here. As far as sending an =22empty=22 POST requests are not = prohibited and function performed is determined by the server and depends= on the effective request URI how do we violate uniformity=3F 
=

Below are several quotes from Roy =46ielding: 

=22Note that POST, regardless of which meaning is= being used, has none of the characteristics that would make it useful fo= r the architecture to know exactly what is going on=22. =5B2=5D

In the same post he defines POST method as =22append-this= =22 and POST method as =22process-this=22. And says:

=
=22POST(a), as =22append this=22, is unsafe, non-idempotent, non-cac= heable, operates on an unknown resource, and has only minor visibility si= nce there is no way for an intermediary to anticipate the state of the re= source after the append aside from =22some state was added=22. POST(p), a= s =22process this=22, doesn't even have that minor visibility. Thus, an a= rchitectural style like REST can only improve the performance of a POST-b= ased architecture by finding ways to escape POST (e.g., 201).=22 =5B2=5D<= /div>

If POST doesn't have visibility and performed fu= nction is dependent on the request URI and no one can know in advance wha= t will be performed:

1) how is it poss= ible to invoke non-uniform method=3F
2) in what sense it's RPC=3F=
3) and how this is different compared to including same inform= ation in the entity body and asking server to do something=3F 
=

> And for some of your desired cases you are even = loosing the visibility a use of PUT would give you. It's effectively RPC,= IMHO.

I do not understand how PUT can help in t= his case.

=5B1=5D. http://tools.ietf.org/html/dr= aft-ietf-httpbis-p2-semantics-21=23section-5.3.3
=5B2=5D. http:= //tech.groups.yahoo.com/group/rest-discuss/message/4732=3Fthreaded=3D1&am= p;p=3D5

Best regards,
ioseb
=20

On Saturday, =46ebruar= y 2, 2013 at 5:50 PM, Jan Algermissen wrote:


On 02.02.2013, at= 12:56, Ioseb Dzmanashvili <ioseb.dzmanashvili=40gmail.com> wrote:

<= /div>
Hi Jan,

=
What happened to the idea that REST me= ans 'representational state transfer' and not 'remote method invocation'=3F=

Sorry for not giving up on this, b= ut i've few questions. I do not want to dive into REST details, but from = REST description, representation is a sequence of bytes + meta data. =46r= om both, REST and HTTP PoV i do not see(or maybe do not understand=3F) wh= y =22Representaiontal=22 part of the style is violated=3F

You are not transferring state to advance t= he application, you are effectively invoking a non-uniform method (e.g. '= publish')

You are not even doing a POST in the s= ense 'take this data and do with it as you please'.

<= div>And for some of your desired cases you are even loosing the visibilit= y a use of PUT would give you. It's effectively RPC, IMHO.

=
Jan



This is the quote from =46ielding's disse= rtation:
What makes HTTP signific= antly different from RPC is that the requests are directed to resources u= sing a generic interface with standard semantics that can be interpreted = by intermediaries almost as well as by the machines that originate servic= es
What do we violate here=3F is there any restric= tion which prevents us from defining processing resources=3F
cheers,
ioseb

On Saturday= , =46ebruary 2, 2013 at 10:26 AM, Jan Algermissen wrote:


On 02.02.2013,= at 01:29, Darrel Miller <darrel.miller=40gmail.com> wrote:



=46or sure= . We can mint rel=3D=22print=22, rel=3D=22start=22, rel=3D=22stop=22, rel= =3D=22restart=22, rel=3D=22launch=22, rel=3D=22publish=22, rel=3D=22submi= t=22, rel =3D=22poke=22, rel=3D=22like=22, rel=3D=22+1=22

What happened to the idea that REST means 'r= epresentational state transfer' and not 'remote method invocation'=3F


Jan
=20 =20 =20 =20
=20

--51181fbf_706b674e_2d6-- From jan.algermissen@nordsc.com Sun Feb 17 02:31:48 2013 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 169A521F87F9 for ; Sun, 17 Feb 2013 02:31:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.313 X-Spam-Level: X-Spam-Status: No, score=0.313 tagged_above=-999 required=5 tests=[AWL=-2.337, BAYES_50=0.001, HELO_EQ_DE=0.35, MANGLED_MARKET=2.3] 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 E-iT981r0iRn for ; Sun, 17 Feb 2013 02:31:47 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF2F21F87EA for ; Sun, 17 Feb 2013 02:31:46 -0800 (PST) Received: from [192.168.2.103] (p548FA63C.dip.t-dialin.net [84.143.166.60]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0Lkxnh-1UhSg63umT-00ak4u; Sun, 17 Feb 2013 11:31:44 +0100 From: Jan Algermissen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Expanding the definition of 'service' link relation type to cover 'Home Documents' Date: Sun, 17 Feb 2013 11:31:46 +0100 Message-Id: <9806641E-9AEA-4AA6-A059-C60F330A7B12@nordsc.com> To: "mnot@mnot.net Nottingham" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Provags-ID: V02:K0:1CewwW4KO/8nSEY2C2YwENf/14I5rQr7x/u8yx56xDj a7feqKsyz8FPKltfzIWW1sKA6mnulZKBtc2GQ5a3w3v+M5UOqH k6nL+MEFAN4TMj4FUO90MZIR05nsBwj/9TGbWyB1kXYkXx2dZ7 RseYIuf6J5iE5QXuqK9LGoYdbSHLbVUNKcfgJL5orVYDqv+dd9 Q0kijzQY5+oN22pMuXSJBDA+X3D7NyBHTf97QNbomRgFepfkjr tyNEDCRaWUFgvncOzGvKp9psVBj+Kw2D+vdDDauYumjlRDD+8a 8zRbHe8PFhbXWB3UvW7OrSnv/BJQLMQ7/93q8vhMkbSNEefMoW Q18zqcpo/3zij08TiTce59d7xUhemVY0zsWxrNsxHGZ1aUwOow 19LO4i9xmZVeg== Cc: link-relations 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: Sun, 17 Feb 2013 10:31:48 -0000 Mark et al, I think it would make sense to expand the definition of the 'service' = link relation type[1] to cover JSON Home[2] documents. Then 'service' could be used to point to the home document from within = representations served from a given API. Much like most Web pages of a = given Web site include the top menu of the site. When I am being given a bookmark into an API, dereferencing that = bookmark would enable me to find the home document without knowing the = API's 'main' entry URI. GET /products/42 ... 200 Ok Link: ;rel=3D"service";title=3D"API Home Document" ... GET /home Accept: application/json-home ... I suggest rewording the definition to something like "Indicates a URI that can be used to retrieve a service- *or home* = document *that enables discovery of resources of a service or Web API*" Thoughts? Jan [1] http://www.iana.org/assignments/link-relations/link-relations.xml [2] http://tools.ietf.org/html/draft-nottingham-json-home-02 From mnot@mnot.net Sun Feb 17 19:30:53 2013 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 A61B421F8B83 for ; Sun, 17 Feb 2013 19:30:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.303 X-Spam-Level: X-Spam-Status: No, score=-104.303 tagged_above=-999 required=5 tests=[AWL=-4.004, BAYES_00=-2.599, MANGLED_MARKET=2.3, 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 je0BNOTnkhso for ; Sun, 17 Feb 2013 19:30:52 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 8DCA121F8B46 for ; Sun, 17 Feb 2013 19:30:52 -0800 (PST) Received: from [192.168.1.80] (unknown [118.209.197.138]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id AB0B1509BB; Sun, 17 Feb 2013 22:30:50 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Expanding the definition of 'service' link relation type to cover 'Home Documents' From: Mark Nottingham In-Reply-To: <9806641E-9AEA-4AA6-A059-C60F330A7B12@nordsc.com> Date: Mon, 18 Feb 2013 14:30:46 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <9F0C98E1-3DCF-49A2-984F-F3D4D6F82892@mnot.net> References: <9806641E-9AEA-4AA6-A059-C60F330A7B12@nordsc.com> To: Jan Algermissen , James M Snell X-Mailer: Apple Mail (2.1499) Cc: link-relations 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, 18 Feb 2013 03:30:53 -0000 That could work. My big concern is that you'd confuse consumers who = think that service implies the use of APP. Using the type parameter will = help, of course. James, what do you think? Probably worth asking on the atom list(s) too... On 17/02/2013, at 9:31 PM, Jan Algermissen = wrote: > Mark et al, >=20 > I think it would make sense to expand the definition of the 'service' = link relation type[1] to cover JSON Home[2] documents. >=20 > Then 'service' could be used to point to the home document from within = representations served from a given API. Much like most Web pages of a = given Web site include the top menu of the site. >=20 > When I am being given a bookmark into an API, dereferencing that = bookmark would enable me to find the home document without knowing the = API's 'main' entry URI. >=20 > GET /products/42 > ... >=20 > 200 Ok > Link: ;rel=3D"service";title=3D"API Home Document" > ... >=20 > GET /home > Accept: application/json-home > ... >=20 > I suggest rewording the definition to something like >=20 > "Indicates a URI that can be used to retrieve a service- *or home* = document *that enables discovery of resources of a service or Web API*" >=20 > Thoughts? >=20 >=20 > Jan >=20 > [1] http://www.iana.org/assignments/link-relations/link-relations.xml > [2] http://tools.ietf.org/html/draft-nottingham-json-home-02 >=20 -- Mark Nottingham http://www.mnot.net/ From derhoermi@gmx.net Mon Feb 18 08:09:04 2013 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 8568421F8B90 for ; Mon, 18 Feb 2013 08:09:04 -0800 (PST) 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 OXhjz0z-gO3K for ; Mon, 18 Feb 2013 08:09:03 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 458F821F8A6B for ; Mon, 18 Feb 2013 08:09:03 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.31]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0Lx1bL-1UwRIi3sc5-016dQK for ; Mon, 18 Feb 2013 17:09:02 +0100 Received: (qmail invoked by alias); 18 Feb 2013 16:09:01 -0000 Received: from p54B4E14B.dip.t-dialin.net (EHLO netb.Speedport_W_700V) [84.180.225.75] by mail.gmx.net (mp031) with SMTP; 18 Feb 2013 17:09:01 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1++vPIAYIK+0MLbi8vRbGR/GnRil0FeZVbS0htWXj VIO83h7GYi5HTl From: Bjoern Hoehrmann To: link-relations@ietf.org Subject: 'meta' link relation Date: Mon, 18 Feb 2013 17:09:03 +0100 Message-ID: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 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, 18 Feb 2013 16:09:04 -0000 Hi, I saw this on the Internet and thought I give this registration thing a whirl... Relation Name: meta Description: Linked metadata. Reference: http://tools.ietf.org/html/draft-daviel-metadata-link-00 http://dublincore.org/documents/dcmes-xml/#sec4 http://www.w3.org/TR/rdf-syntax-grammar/#section-rdf-in-HTML regards, -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From dret@berkeley.edu Mon Feb 18 14:19:05 2013 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 4407221F8C5C for ; Mon, 18 Feb 2013 14:19:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.016 X-Spam-Level: ** X-Spam-Status: No, score=2.016 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_SORBS_WEB=0.619] 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 HPfehRKTyfjq for ; Mon, 18 Feb 2013 14:19:03 -0800 (PST) Received: from gong.birdhouse.org (gong.birdhouse.org [207.58.180.215]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9D921F8C58 for ; Mon, 18 Feb 2013 14:19:03 -0800 (PST) Received: from [217.110.189.162] (port=61373 helo=[10.59.1.252]) by gong.birdhouse.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1U7Z37-0004aV-M9; Mon, 18 Feb 2013 14:19:02 -0800 References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <1F9058DC-B7CF-4F8B-9329-D8F4FFEFE34E@berkeley.edu> X-Mailer: iPhone Mail (10B144) From: Erik Wilde Subject: Re: 'meta' link relation Date: Mon, 18 Feb 2013 23:18:58 +0100 To: Bjoern Hoehrmann X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gong.birdhouse.org X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - berkeley.edu X-Get-Message-Sender-Via: gong.birdhouse.org: authenticated_id: birdhouse+dret.net/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: 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: Mon, 18 Feb 2013 22:19:05 -0000 hello bj=C3=B6rn. On Feb 18, 2013, at 17:09, Bjoern Hoehrmann wrote > I saw this on the Internet and thought I give this registration thing > a whirl... > Relation Name: > meta > Description: > Linked metadata. what about using the already existing "describedby" link relation, which is i= ntended for pretty much exactly this kind of scenario? cheers, dret.= From algermissen1971@me.com Tue Feb 19 00:01:34 2013 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 C804321F8D6F for ; Tue, 19 Feb 2013 00:01:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.542 X-Spam-Level: X-Spam-Status: No, score=-6.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 nWMmtgFnD45r for ; Tue, 19 Feb 2013 00:01:34 -0800 (PST) Received: from nk11p03mm-asmtp002.mac.com (nk11p03mm-asmtp002.mac.com [17.158.232.237]) by ietfa.amsl.com (Postfix) with ESMTP id 3984221F8CBD for ; Tue, 19 Feb 2013 00:01:33 -0800 (PST) Received: from [192.168.2.103] ([84.143.158.91]) by nk11p03mm-asmtp002.mac.com (Oracle Communications Messaging Server 7u4-26.01(7.0.4.26.0) 64bit (built Jul 13 2012)) with ESMTPSA id <0MIG008JDJM6R2A0@nk11p03mm-asmtp002.mac.com> for link-relations@ietf.org; Tue, 19 Feb 2013 08:01:21 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327,1.0.431,0.0.0000 definitions=2013-02-18_07:2013-02-18, 2013-02-18, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1302180415 From: algermissen1971 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Subject: Remarks for draft-wmills-oauth-lrdd-07 Date: Tue, 19 Feb 2013 09:01:19 +0100 Message-id: To: "wmills_92105@yahoo.com" MIME-version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Mailman-Approved-At: Tue, 19 Feb 2013 00:02:23 -0800 Cc: link-relations 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, 19 Feb 2013 08:01:34 -0000 William, thanks for incorporating the changes[1]. Persionally, I am always trying to avoid semantic overlap between specs = and with that hat on, I still have problems with the various link = relations being tied to specific OAuth versions. I'll go through the specific definitions again over the next days to see = if I can sustain my point that, at least for some of them, the specific = OAuth version does not matter but is rather a runtime capability = negotiation issue. Please bear with me :-) Jan [1] http://www.ietf.org/rfcdiff?url2=3Ddraft-wmills-oauth-lrdd-07= From jan.algermissen@nordsc.com Tue Feb 19 00:09:37 2013 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 F2B1621F8D74 for ; Tue, 19 Feb 2013 00:09:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[AWL=0.372, 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 f6zjM5ypSnao for ; Tue, 19 Feb 2013 00:09:36 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id B6DD021F8D70 for ; Tue, 19 Feb 2013 00:09:27 -0800 (PST) Received: from [192.168.2.103] (p548F9E5B.dip.t-dialin.net [84.143.158.91]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0M94Cf-1U1upc1kEP-00D1sn; Tue, 19 Feb 2013 09:09:25 +0100 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: 'meta' link relation From: Jan Algermissen In-Reply-To: <1F9058DC-B7CF-4F8B-9329-D8F4FFEFE34E@berkeley.edu> Date: Tue, 19 Feb 2013 09:09:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <94C43798-051C-4A62-AD39-0B035A0CB8B6@nordsc.com> References: <1F9058DC-B7CF-4F8B-9329-D8F4FFEFE34E@berkeley.edu> To: Erik Wilde X-Mailer: Apple Mail (2.1499) X-Provags-ID: V02:K0:LRxA2Th89pmxGa0dJ/s1bE7k5SaQGb4GFABGAAaMlpl jGm/zqS7sAzRSKXWyTbAqk/L5YK/Cjs/tJj/MxuSOHFkA9F21o Y9UjuH8xSMfNdwogDEgKWC2ZC1TqnG1brxEjXxCShcndhP38iP 0ypJkgoxHkiEhQQhu1/a+y3+hQDC8p47cwPGJvG/lAoJhOoGpw g5m6FJxwXCQ6jIUhabyWzfQMD3+IwUyjzkiaNm4aN/MzqzRbaD mgF5LUlKKcOOPxhmC7Em8UJRyi0ek72nd94NTxc6LpWAHQs33G 9gfDqGmVmVmd7sFWyd8DViOik/cHtFlXGb9U6a3RbfkFeOjDQl XUPUQMutSHlTK1dJdBIOpQJUm7HHLVam/o42or2MqXic93Mtkc zMY0OPakuhwmw== Cc: Bjoern Hoehrmann , "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, 19 Feb 2013 08:09:37 -0000 On 18.02.2013, at 23:18, Erik Wilde wrote: > hello bj=F6rn. >=20 > On Feb 18, 2013, at 17:09, Bjoern Hoehrmann wrote >> I saw this on the Internet and thought I give this registration thing >> a whirl... >> Relation Name: >> meta >> Description: >> Linked metadata. >=20 > what about using the already existing "describedby" link relation, = which is intended for pretty much exactly this kind of scenario? +++1 :-) Jan >=20 > cheers, >=20 > dret. > _______________________________________________ > link-relations mailing list > link-relations@ietf.org > https://www.ietf.org/mailman/listinfo/link-relations From mikekelly321@gmail.com Tue Feb 19 00:21:21 2013 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 244CE21F8D92 for ; Tue, 19 Feb 2013 00:21:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.100, 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 Sv6jdEJx1y6f for ; Tue, 19 Feb 2013 00:21:15 -0800 (PST) Received: from mail-ee0-f41.google.com (mail-ee0-f41.google.com [74.125.83.41]) by ietfa.amsl.com (Postfix) with ESMTP id 5641A21F8D96 for ; Tue, 19 Feb 2013 00:21:14 -0800 (PST) Received: by mail-ee0-f41.google.com with SMTP id c13so3225810eek.14 for ; Tue, 19 Feb 2013 00:21:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=0oMcjV39O40a6/0OzzMqZcjtJ0I8dq8yfropbR2g+xE=; b=aupjjLVf8MzrDDTbhD8PlfkZJk2lAUzNAbAc+y5ZuW50Wt4JdDDMLDSSt55J4mhlWN OnkYl7pSHI+UcaWhAK4g1yLQVNoLe6JxW3YiCs7pABn3J3jqHGBzEgjm9zeb+kE7GucO nEFlxrui4SMjIOZ8Ut4o4nbbyPykP3GEcrgmq7P8BosXjcuRf6HEiyt4lJctNh9HNK4d B2OW3X6Nlv0YO/uIkTBBQDVv44lJzIMf4BCFLqmYQN+LZbXN1IM5J0K10a0s5kX75xH9 sJgE5hIW4GaoHE9HSzQb4UIlpgrC9mT7q3gXhByfOM0RuxNeKwGjiKM92hXLQ1xPjImp CMbA== MIME-Version: 1.0 X-Received: by 10.14.184.68 with SMTP id r44mr54000488eem.40.1361262073414; Tue, 19 Feb 2013 00:21:13 -0800 (PST) Received: by 10.223.168.10 with HTTP; Tue, 19 Feb 2013 00:21:13 -0800 (PST) Received: by 10.223.168.10 with HTTP; Tue, 19 Feb 2013 00:21:13 -0800 (PST) In-Reply-To: <94C43798-051C-4A62-AD39-0B035A0CB8B6@nordsc.com> References: <1F9058DC-B7CF-4F8B-9329-D8F4FFEFE34E@berkeley.edu> <94C43798-051C-4A62-AD39-0B035A0CB8B6@nordsc.com> Date: Tue, 19 Feb 2013 08:21:13 +0000 Message-ID: Subject: Re: 'meta' link relation From: Mike Kelly To: Jan Algermissen Content-Type: multipart/alternative; boundary=047d7b3438ec55025d04d60f8612 Cc: Bjoern Hoehrmann , 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, 19 Feb 2013 08:21:21 -0000 --047d7b3438ec55025d04d60f8612 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Consider it a synonym, then. If this is used in the wild it should be registered. On a slightly meta tangent.. Is there an acceptance criteria for link relations or do you just make it up as you go along? Cheers, M On 19 Feb 2013 08:09, "Jan Algermissen" wrote: > > On 18.02.2013, at 23:18, Erik Wilde wrote: > > > hello bj=F6rn. > > > > On Feb 18, 2013, at 17:09, Bjoern Hoehrmann wrote > >> I saw this on the Internet and thought I give this registration thing > >> a whirl... > >> Relation Name: > >> meta > >> Description: > >> Linked metadata. > > > > what about using the already existing "describedby" link relation, whic= h > is intended for pretty much exactly this kind of scenario? > > +++1 :-) > > Jan > > > > > > cheers, > > > > dret. > > _______________________________________________ > > link-relations mailing list > > link-relations@ietf.org > > https://www.ietf.org/mailman/listinfo/link-relations > > _______________________________________________ > link-relations mailing list > link-relations@ietf.org > https://www.ietf.org/mailman/listinfo/link-relations > --047d7b3438ec55025d04d60f8612 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Consider it a synonym,=A0 then. If this is used in the wild = it should be registered.

On a slightly meta tangent.. Is there an acceptance criteria= for link relations or do you just make it up as you go along?

Cheers,
M

On 19 Feb 2013 08:09, "Jan Algermissen"= ; <jan.algermissen@nordsc.= com> wrote:

On 18.02.2013, at 23:18, Erik Wilde <dret@berkeley.edu> wrote:

> hello bj=F6rn.
>
> On Feb 18, 2013, at 17:09, Bjoern Hoehrmann <derhoermi@gmx.net> wrote
>> I saw this on the Internet and thought I give this registration th= ing
>> a whirl...
>> Relation Name:
>> =A0 meta
>> Description:
>> =A0 Linked metadata.
>
> what about using the already existing "describedby" link rel= ation, which is intended for pretty much exactly this kind of scenario?

+++1 :-)

Jan


>
> cheers,
>
> dret.
> _______________________________________________
> link-relations mailing list
> link-relations@ietf.org=
> https://www.ietf.org/mailman/listinfo/link-relations

_______________________________________________
link-relations mailing list
link-relations@ietf.org
https://www.ietf.org/mailman/listinfo/link-relations
--047d7b3438ec55025d04d60f8612-- From jan.algermissen@nordsc.com Tue Feb 19 00:33:48 2013 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 B8F0821F86FD for ; Tue, 19 Feb 2013 00:33:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 tagged_above=-999 required=5 tests=[AWL=0.335, 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 lKG4lW1vCvgD for ; Tue, 19 Feb 2013 00:33:48 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id EC25821F869C for ; Tue, 19 Feb 2013 00:33:47 -0800 (PST) Received: from [192.168.2.103] (p548F9E5B.dip.t-dialin.net [84.143.158.91]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0McRym-1UPO1K369I-00IA5D; Tue, 19 Feb 2013 09:33:46 +0100 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: 'meta' link relation From: Jan Algermissen In-Reply-To: Date: Tue, 19 Feb 2013 09:33:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1F9058DC-B7CF-4F8B-9329-D8F4FFEFE34E@berkeley.edu> <94C43798-051C-4A62-AD39-0B035A0CB8B6@nordsc.com> To: Mike Kelly X-Mailer: Apple Mail (2.1499) X-Provags-ID: V02:K0:TvifVVxaZ88bNqgMwyucPc7ds8j+wu3G3T3bZpRr8q/ /O/93hRUeSPerkP0Z4XAqpsp5qlMQfqtz/keY7jCEEiaagkEdY QtUPHNalVyK8pCvzhvr24doM44LNxaVmof14zOXo6ul1hQtDM4 a8oMoU7G9PJyiGuRd+WiVRvRobzDG5bAxYAC2Q6JsUgxvBgNoE S8v+QLm5+Q5Lpqi/45xG42qK+k++IFCdNe8a2O5Fhvj1e9Udu8 ZYPTtACUTNlS8AfHBz/p6y9/ZKomTVnSE7yF4zV7pwmeJSBeWG E0Sv3Ch21GLx9dZ/QLXrkW+dlFqktfBLOsfMifEsn05HJ9I4VZ prPBF6euzglH3So9i0tiyKmBtGik2hqWfqFcYpHjNDe3qrb51q TnpCTMV6ZvUrQ== Cc: Bjoern Hoehrmann , 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, 19 Feb 2013 08:33:48 -0000 On 19.02.2013, at 09:21, Mike Kelly wrote: > Consider it a synonym, then. If this is used in the wild it should be = registered. To me it is the other way round, really. Just because you spot = something, doesn't mean you need to standardize it. >=20 > On a slightly meta tangent.. Is there an acceptance criteria for link = relations or do you just make it up as you go along? To me: - No semantic overlap - No manifestation of Web anti patterns (e.g. the recent 'action' link = rel type) - Genericity (e.g. avoid having an OAuth1 and OAuth2 version of = essentially the same semantic) Jan >=20 > Cheers, > M >=20 > On 19 Feb 2013 08:09, "Jan Algermissen" = wrote: >=20 > On 18.02.2013, at 23:18, Erik Wilde wrote: >=20 > > hello bj=F6rn. > > > > On Feb 18, 2013, at 17:09, Bjoern Hoehrmann = wrote > >> I saw this on the Internet and thought I give this registration = thing > >> a whirl... > >> Relation Name: > >> meta > >> Description: > >> Linked metadata. > > > > what about using the already existing "describedby" link relation, = which is intended for pretty much exactly this kind of scenario? >=20 > +++1 :-) >=20 > Jan >=20 >=20 > > > > cheers, > > > > dret. > > _______________________________________________ > > link-relations mailing list > > link-relations@ietf.org > > https://www.ietf.org/mailman/listinfo/link-relations >=20 > _______________________________________________ > link-relations mailing list > link-relations@ietf.org > https://www.ietf.org/mailman/listinfo/link-relations From julian.reschke@gmx.de Tue Feb 19 00:36:07 2013 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 5AF2C21F8726 for ; Tue, 19 Feb 2013 00:36:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.932 X-Spam-Level: X-Spam-Status: No, score=-103.932 tagged_above=-999 required=5 tests=[AWL=-1.333, 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 8CuYKRFVUNnh for ; Tue, 19 Feb 2013 00:36:06 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 9D19421F87EE for ; Tue, 19 Feb 2013 00:36:06 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.34]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MFOSw-1U4N9N31Lo-00EPjN for ; Tue, 19 Feb 2013 09:36:05 +0100 Received: (qmail invoked by alias); 19 Feb 2013 08:36:05 -0000 Received: from p54BB2D43.dip.t-dialin.net (EHLO [192.168.1.102]) [84.187.45.67] by mail.gmx.net (mp034) with SMTP; 19 Feb 2013 09:36:05 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18+pfdPmLM+cTRJa62754pR2UXi+/qqJWOoz964Tj 6ZOEPP8Np1VsAt Message-ID: <51233975.3070309@gmx.de> Date: Tue, 19 Feb 2013 09:36:05 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Mike Kelly Subject: Re: 'meta' link relation References: <1F9058DC-B7CF-4F8B-9329-D8F4FFEFE34E@berkeley.edu> <94C43798-051C-4A62-AD39-0B035A0CB8B6@nordsc.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Bjoern Hoehrmann , 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, 19 Feb 2013 08:36:07 -0000 On 2013-02-19 09:21, Mike Kelly wrote: > Consider it a synonym, then. If this is used in the wild it should be > registered. If it used a *lot*, yes. Is it? > On a slightly meta tangent.. Is there an acceptance criteria for link > relations or do you just make it up as you go along? RFC 5988. Best regards, Julian From mikekelly321@gmail.com Tue Feb 19 00:49:32 2013 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 4A67221F8758 for ; Tue, 19 Feb 2013 00:49:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 csPmwp8138Ct for ; Tue, 19 Feb 2013 00:49:31 -0800 (PST) Received: from mail-ee0-f49.google.com (mail-ee0-f49.google.com [74.125.83.49]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5FD21F8726 for ; Tue, 19 Feb 2013 00:49:20 -0800 (PST) Received: by mail-ee0-f49.google.com with SMTP id d4so3293508eek.36 for ; Tue, 19 Feb 2013 00:49:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=gynnjFBVjelrsE/pO9lz5m39VxyKSIx6xvRqTawXiQU=; b=mGS7ltGHJrn7hE357ijuXn6yjLcOAMIiTrZVhErICVhRnfRUPNUPkf4ibVja8im2m3 VmO4KcVKrAl5Ieb4p03IaEUOi8jEsKxaUU/YnHLwxbz+TPBGluC/UcBfHGjquAD8ZzTW RXEj/CUoz/Xz4gOBDx/PhwssecStPcEBdmV5H5SuhhvvIomJwPS+0CF54yztMSR7nrJa yl6nXyzymT2T/e5AV6Oifrno4UpFEXj4lr7W4WMHYhmziQ75Y+mqRRVmALuAIDsLybEm SjRNW09HGgMTBi55mo7FlF2im3lz3uyguNrTeqGzKaxMD1nsyJAG5fbuFcBbYympqH6d VNkw== MIME-Version: 1.0 X-Received: by 10.14.184.68 with SMTP id r44mr54243511eem.40.1361263755762; Tue, 19 Feb 2013 00:49:15 -0800 (PST) Received: by 10.223.168.10 with HTTP; Tue, 19 Feb 2013 00:49:15 -0800 (PST) In-Reply-To: <51233975.3070309@gmx.de> References: <1F9058DC-B7CF-4F8B-9329-D8F4FFEFE34E@berkeley.edu> <94C43798-051C-4A62-AD39-0B035A0CB8B6@nordsc.com> <51233975.3070309@gmx.de> Date: Tue, 19 Feb 2013 08:49:15 +0000 Message-ID: Subject: Re: 'meta' link relation From: Mike Kelly To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Cc: Bjoern Hoehrmann , 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, 19 Feb 2013 08:49:32 -0000 On Tue, Feb 19, 2013 at 8:36 AM, Julian Reschke wrote: > On 2013-02-19 09:21, Mike Kelly wrote: >> >> Consider it a synonym, then. If this is used in the wild it should be >> registered. > > > If it used a *lot*, yes. Is it? > How much is "a *lot*"? I checked RFC 5988 and it doesn't say. :) >> On a slightly meta tangent.. Is there an acceptance criteria for link >> relations or do you just make it up as you go along? > > > RFC 5988. > please could you be more specific? I can't see any criteria defined, just process Cheers, M From mikekelly321@gmail.com Tue Feb 19 00:54:18 2013 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 F198921F8D33 for ; Tue, 19 Feb 2013 00:54:16 -0800 (PST) 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=[AWL=0.000, 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 CNuM5siVfE-B for ; Tue, 19 Feb 2013 00:54:16 -0800 (PST) Received: from mail-ea0-f176.google.com (mail-ea0-f176.google.com [209.85.215.176]) by ietfa.amsl.com (Postfix) with ESMTP id 4007221F8CB5 for ; Tue, 19 Feb 2013 00:54:15 -0800 (PST) Received: by mail-ea0-f176.google.com with SMTP id a13so2799419eaa.21 for ; Tue, 19 Feb 2013 00:54:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=pmPZr0ofyIuU6S1FPnBWMIPTyDyiX7v9H4Ps4DojD8E=; b=TVHKZ8b6nSzJgKGaz55pNvJQfEOG24mcd/jmWcG1XRfXtBSV1OGQioVaA9k3T5iR8F ++5H1DD45Gvj5pIHhyWVx1TS9fJDE9D2I4lp+52jOIKAUrfKCkpdyYoEoaT6ijHZhtXT f28MhZizTYYZdFcyqqX7QwwrHXS/LGlSSSImHPxjpTe9l8DFq+9to8YPLKNcXAydo4pf yhjyDFni6xOzA5qekQnf4+IqeGJnpUt1lgBnf1hHEeGbW7cX0SU8lmv4DzmcP2ImwKhN obwhpDztL8bFBfOB4HCw9kEs84Z3pWmWg+I40vD4ipEKwoH6uVpEotqbMH2M3SGYwD/U oNRw== MIME-Version: 1.0 X-Received: by 10.14.3.70 with SMTP id 46mr55077122eeg.2.1361264054179; Tue, 19 Feb 2013 00:54:14 -0800 (PST) Received: by 10.223.168.10 with HTTP; Tue, 19 Feb 2013 00:54:14 -0800 (PST) In-Reply-To: References: <1F9058DC-B7CF-4F8B-9329-D8F4FFEFE34E@berkeley.edu> <94C43798-051C-4A62-AD39-0B035A0CB8B6@nordsc.com> Date: Tue, 19 Feb 2013 08:54:14 +0000 Message-ID: Subject: Re: 'meta' link relation From: Mike Kelly To: Jan Algermissen Content-Type: text/plain; charset=ISO-8859-1 Cc: Bjoern Hoehrmann , 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, 19 Feb 2013 08:54:18 -0000 On Tue, Feb 19, 2013 at 8:33 AM, Jan Algermissen wrote: > > On 19.02.2013, at 09:21, Mike Kelly wrote: >> >> On a slightly meta tangent.. Is there an acceptance criteria for link relations or do you just make it up as you go along? > > To me: > > - No semantic overlap Over time, I think you will struggle to live with this constraint. What is the damage is the semantics do overlap? Presumably the rel definitions can make reference to one another where this is the case? Cheers, M From wmills_92105@yahoo.com Tue Feb 19 01:30:47 2013 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 BAED021F8D79 for ; Tue, 19 Feb 2013 01:30:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.342 X-Spam-Level: X-Spam-Status: No, score=-2.342 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 yZfvbzvJrtNj for ; Tue, 19 Feb 2013 01:30:47 -0800 (PST) Received: from nm5.bullet.mail.bf1.yahoo.com (nm5.bullet.mail.bf1.yahoo.com [98.139.212.164]) by ietfa.amsl.com (Postfix) with SMTP id 02F5521F8D57 for ; Tue, 19 Feb 2013 01:30:46 -0800 (PST) Received: from [98.139.212.152] by nm5.bullet.mail.bf1.yahoo.com with NNFMP; 19 Feb 2013 09:30:46 -0000 Received: from [98.139.212.222] by tm9.bullet.mail.bf1.yahoo.com with NNFMP; 19 Feb 2013 09:30:46 -0000 Received: from [127.0.0.1] by omp1031.mail.bf1.yahoo.com with NNFMP; 19 Feb 2013 09:30:46 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 545221.7605.bm@omp1031.mail.bf1.yahoo.com Received: (qmail 53634 invoked by uid 60001); 19 Feb 2013 09:30:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1361266245; bh=koar+F8CtgsNUf5AV+iQoEnirbyprefXVdRm27zikBM=; 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; b=xJnh1IeSFYLnLtDCDCAOknIudPtX+LYSCAdN3UMKB2f0Dpt+ApIQaoAwBJCIN/sxx5GRBajuFDU0bHOn0ftkGSLWy7wiimfYjP+MXZbITOzsfFp+KosiUtQcY8dQldTBebtEXGiq7UtFNjlA1jiholMr+4/bkkAPjreEr8iO2hs= 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; b=vyyt3d6scnwE5Rg9LUDpmyTgs9VsYg6+8jyEQrJTXrB+JRAwPdU2t/ozXujj5E5WTJRXTRyvNNiVPXQfPSweAk2EF6CDoCWEzHFcwi23obbhQBYbhvgitZEzRDJ2jQfPQtV8d2jFfoz0s1SCJiYNJTt0/BuWcViqu2jhzmtLzoc=; X-YMail-OSG: UQaiabMVM1lFhbI2ZXE00hUjwtsnGGb8RHBsFFT1IeKtpAA fbHcMGw9drE80daoqQ5ydDIBfSJIdZimgCF8OrogPI6yUJWvWmOGHqzh9cUe 5XBx.GmFPXAH.rv4b5KsFyuUDr3Dt2e5INpOanvTMwzgP5LJiwkLOrHr45Jm H8hRQQMOiXw2EAxCB.vIkBCt7GZru6Qw0LBtBHyF4MbHm6YyeWc_X06VmvVq 0cRv2D534XQ3O1LbJN2iPdLdl0ylJvBtMVals2FThU6DAtgo6us_Jokla4Tv Zh1XrMR1B_Fu_3uYrM3kzj8wfFD7MjYfxP1VmZ5rVH2N3NWqv5OhoNs31eE1 HAUKIUBeqaFKijUTqWBrLzPTzk.f1pueYKj6mVQEuO.mG.TUGgN0uCEerIX6 n7OwAA0fh7L1NudsgPjjAJhaLljqQoZAUeJl8mf.f6.NpHROXkuivkYqJMd1 6Rj2_NgUNq0dA1551hG6OmnXAClrWk3_j6NWZ_nBVoIOKQSKJS6KpsOfV2jf Q3Iw55DuEH6vpfAItJrXm0jp2c2jJ61x5.Fs8bg-- Received: from [209.131.62.115] by web31805.mail.mud.yahoo.com via HTTP; Tue, 19 Feb 2013 01:30:45 PST X-Rocket-MIMEInfo: 001.001, SSBhZ3JlZSB0aGF0IHRoZXkgb3ZlcmxhcC4gwqBJJ20gb3BlbiB0byBhbnkgY2xlYXIgd2F5IHRvIHJlcHJlc2VudCB0aGlzLCBJIGNob3NlIG5vdCB0byBnbyB3aXRoIGEgInZlcnNpb24iIGxpbmsgZXh0ZW5zaW9uLCBzaW5jZSBpdCdzIGluY3JlbWVudGFsbHkgKGJ5IHRoYXTCoGluZmluaXRlc2ltYWzCoGNhbGN1bHVzIGR4KSBtb3JlIGNvbXBsaWNhdGVkIGFuZCBpdCB0aGVuIHJlcXVpcmVzIGEgcmVnaXN0cnkgb2YgY29uc3RhbnRzLgoKRGlzY3Vzc2lvbiBpcyBmb3J3YXJkIHByb2dyZXNzLCBzbyBJJ20BMAEBAQE- X-Mailer: YahooMailWebService/0.8.134.513 References: Message-ID: <1361266245.51526.YahooMailNeo@web31805.mail.mud.yahoo.com> Date: Tue, 19 Feb 2013 01:30:45 -0800 (PST) From: William Mills Subject: Re: Remarks for draft-wmills-oauth-lrdd-07 To: algermissen1971 In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-551393103-251226037-1361266245=:51526" Cc: link-relations 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: Tue, 19 Feb 2013 09:30:47 -0000 ---551393103-251226037-1361266245=:51526 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I agree that they overlap. =A0I'm open to any clear way to represent this, = I chose not to go with a "version" link extension, since it's incrementally= (by that=A0infinitesimal=A0calculus dx) more complicated and it then requi= res a registry of constants.=0A=0ADiscussion is forward progress, so I'm ha= ppy.=0A=0A-bill=0A=0A=0A________________________________=0A From: algermiss= en1971 =0ATo: "wmills_92105@yahoo.com" =0ACc: link-relations =0ASent: Tuesd= ay, February 19, 2013 12:01 AM=0ASubject: Remarks for draft-wmills-oauth-lr= dd-07=0A =0AWilliam,=0A=0Athanks for incorporating the changes[1].=0A=0APer= sionally, I am always trying to avoid semantic overlap between specs and wi= th that hat on, I still have problems with the various link relations being= tied to specific OAuth versions.=0A=0AI'll go through the specific definit= ions again over the next days to see if I can sustain my point that, at lea= st for some of them, the specific OAuth version does not matter but is rath= er a runtime capability negotiation issue.=0A=0APlease bear with me :-)=0A= =0AJan=0A=0A[1] http://www.ietf.org/rfcdiff?url2=3Ddraft-wmills-oauth-lrdd-= 07 ---551393103-251226037-1361266245=:51526 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I agree that they overlap.  I'm open to any clear w= ay to represent this, I chose not to go with a "version" link extension, si= nce it's incrementally (by that infinitesimal&= nbsp;calculus dx) more complicated and it then requires a registry of const= ants.

<= /font>
Discussion = is forward progress, so I'm happy.

-bill

From: algermissen1971 <algermissen1971@me.com>
To: "wmills_92105@yahoo.com" <wmills_92105@yahoo.com>
C= c: link-relations <link-relations@ietf.org>
Sent: Tuesday, February 19, 2013 12= :01 AM
Subject: Remark= s for draft-wmills-oauth-lrdd-07

=0AWilliam,

= thanks for incorporating the changes[1].

Persionally, I am always tr= ying to avoid semantic overlap between specs and with that hat on, I still = have problems with the various link relations being tied to specific OAuth = versions.

I'll go through the specific definitions again over the ne= xt days to see if I can sustain my point that, at least for some of them, t= he specific OAuth version does not matter but is rather a runtime capabilit= y negotiation issue.

Please bear with me :-)

Jan

[1] h= ttp://www.ietf.org/rfcdiff?url2=3Ddraft-wmills-oauth-lrdd-07

=
---551393103-251226037-1361266245=:51526-- From julian.reschke@gmx.de Tue Feb 19 01:44:27 2013 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 2C1DF21F8C2F for ; Tue, 19 Feb 2013 01:44:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.742 X-Spam-Level: X-Spam-Status: No, score=-103.742 tagged_above=-999 required=5 tests=[AWL=-1.143, 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 A2N0HpPT90bS for ; Tue, 19 Feb 2013 01:44:26 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 663AB21F8B2B for ; Tue, 19 Feb 2013 01:44:26 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.19]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MFfRr-1U4DUq2P7l-00EfNA for ; Tue, 19 Feb 2013 10:44:25 +0100 Received: (qmail invoked by alias); 19 Feb 2013 09:44:25 -0000 Received: from p54BB2D43.dip.t-dialin.net (EHLO [192.168.1.102]) [84.187.45.67] by mail.gmx.net (mp019) with SMTP; 19 Feb 2013 10:44:25 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18Aa/gPbPYAT/2jKJsnm4ZbkP+7QYtFEgd9ZFWEIg beJO7p49zDTvg3 Message-ID: <51234977.7050401@gmx.de> Date: Tue, 19 Feb 2013 10:44:23 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Jan Algermissen Subject: Re: 'meta' link relation References: <1F9058DC-B7CF-4F8B-9329-D8F4FFEFE34E@berkeley.edu> <94C43798-051C-4A62-AD39-0B035A0CB8B6@nordsc.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Bjoern Hoehrmann , 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, 19 Feb 2013 09:44:27 -0000 On 2013-02-19 09:33, Jan Algermissen wrote: > > On 19.02.2013, at 09:21, Mike Kelly wrote: > >> Consider it a synonym, then. If this is used in the wild it should be registered. > > To me it is the other way round, really. Just because you spot something, doesn't mean you need to standardize it. Yes. Note that this case may be different; it would be interesting to see this used in practice. >> On a slightly meta tangent.. Is there an acceptance criteria for link relations or do you just make it up as you go along? > > To me: > > - No semantic overlap I believe that's a good goal. Duplicates are bad for network effects. > - No manifestation of Web anti patterns (e.g. the recent 'action' link rel type) Yes. > - Genericity (e.g. avoid having an OAuth1 and OAuth2 version of essentially the same semantic) Yes. Best regards, Julian From ioseb.dzmanashvili@gmail.com Tue Feb 19 03:07:38 2013 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 2481921F8C7A for ; Tue, 19 Feb 2013 03:07:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[AWL=0.322, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 nS13dOR5UnQk for ; Tue, 19 Feb 2013 03:07:37 -0800 (PST) Received: from mail-ea0-f176.google.com (mail-ea0-f176.google.com [209.85.215.176]) by ietfa.amsl.com (Postfix) with ESMTP id 39FAD21F8C61 for ; Tue, 19 Feb 2013 03:07:37 -0800 (PST) Received: by mail-ea0-f176.google.com with SMTP id a13so2934937eaa.35 for ; Tue, 19 Feb 2013 03:07:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=FpgijshqaRyu67cTMSvg7kF26ee6R5YxC7j0QyPp5Rs=; b=VF3rKLzXH3A+Wsh6D1EH0NY33ucaQLvB6lkxC2+/LScxdNJTao+2RsQNZvy/b1BcHa z/SgNiyDoDspFbd/qRCWpQ2Af0EANqLd7G6mUNxUi6h49rDec/CoYqpD8KAvFwsxayCv CmyZkRjeTkwxC3iRwyFjUjqJ3oRt/3l5gufLW/v0h2MiTKVhH7aGmspcDeM1/fi6ybM5 gmy7PO3wu7Drbz75DkMTcG+uZlFanvlJvpRn5cDyII8ZieBSjj7lLfjQ/OdG6iQmhVUN 0xlqhlzPWCvuWl7iMBgfdJv7CiMJ5lznAXHpFr97GawRs7W0vh3iRL9+hrPRHJGOAXOd cOqg== X-Received: by 10.14.211.132 with SMTP id w4mr55500261eeo.36.1361272056334; Tue, 19 Feb 2013 03:07:36 -0800 (PST) Received: from [10.131.33.114] ([213.131.60.234]) by mx.google.com with ESMTPS id q5sm103380356eeo.17.2013.02.19.03.07.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Feb 2013 03:07:34 -0800 (PST) References: <1F9058DC-B7CF-4F8B-9329-D8F4FFEFE34E@berkeley.edu> <94C43798-051C-4A62-AD39-0B035A0CB8B6@nordsc.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <94F8694B-EB35-443B-BF25-0A5DE40B8236@gmail.com> X-Mailer: iPhone Mail (10B145) From: Ioseb Dzmanashvili Subject: Re: 'meta' link relation Date: Tue, 19 Feb 2013 15:07:33 +0400 To: Jan Algermissen Cc: Bjoern Hoehrmann , "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, 19 Feb 2013 11:07:38 -0000 On Feb 19, 2013, at 12:33 PM, Jan Algermissen w= rote: >=20 > On 19.02.2013, at 09:21, Mike Kelly wrote: >=20 >> Consider it a synonym, then. If this is used in the wild it should be re= gistered. >=20 > To me it is the other way round, really. Just because you spot something, d= oesn't mean you need to standardize it. >=20 >>=20 >> On a slightly meta tangent.. Is there an acceptance criteria for link rel= ations or do you just make it up as you go along? >=20 > To me: >=20 > - No semantic overlap > - No manifestation of Web anti patterns (e.g. the recent 'action' link rel= type) Looks like that "action" being considered anti pattern of web, boils down to= personal prefereneces and understanding. I didn't find any 100% proof of th= is. Nor strong enough arguments were presented during discussion. looks like= i must accept "verdict" anyway :-) > - Genericity (e.g. avoid having an OAuth1 and OAuth2 version of essentiall= y the same semantic) >=20 > Jan >=20 >=20 >>=20 >> Cheers, >> M >>=20 >> On 19 Feb 2013 08:09, "Jan Algermissen" wrot= e: >>=20 >> On 18.02.2013, at 23:18, Erik Wilde wrote: >>=20 >>> hello bj=C3=B6rn. >>>=20 >>> On Feb 18, 2013, at 17:09, Bjoern Hoehrmann wrote >>>> I saw this on the Internet and thought I give this registration thing >>>> a whirl... >>>> Relation Name: >>>> meta >>>> Description: >>>> Linked metadata. >>>=20 >>> what about using the already existing "describedby" link relation, which= is intended for pretty much exactly this kind of scenario? >>=20 >> +++1 :-) >>=20 >> Jan >>=20 >>=20 >>>=20 >>> cheers, >>>=20 >>> dret. >>> _______________________________________________ >>> link-relations mailing list >>> link-relations@ietf.org >>> https://www.ietf.org/mailman/listinfo/link-relations >>=20 >> _______________________________________________ >> link-relations mailing list >> link-relations@ietf.org >> https://www.ietf.org/mailman/listinfo/link-relations >=20 >=20 Sorry for off top. Cheers, ioseb= From derhoermi@gmx.net Tue Feb 19 03:34:13 2013 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 8956321F8B5E for ; Tue, 19 Feb 2013 03:34:13 -0800 (PST) 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 uv4jY7P8Jyc2 for ; Tue, 19 Feb 2013 03:34:12 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADB921F8AD8 for ; Tue, 19 Feb 2013 03:34:12 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.34]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0M1Cg2-1V0q5b0Z56-00tFqf for ; Tue, 19 Feb 2013 12:34:11 +0100 Received: (qmail invoked by alias); 19 Feb 2013 11:34:10 -0000 Received: from p54B4E9AA.dip.t-dialin.net (EHLO netb.Speedport_W_700V) [84.180.233.170] by mail.gmx.net (mp034) with SMTP; 19 Feb 2013 12:34:10 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX19MvWpvOQJMcRN7OV4ficze4WuDUhIF3m+h+F4bXu dJND7zGWA0GVXU From: Bjoern Hoehrmann To: Julian Reschke Subject: Re: 'meta' link relation Date: Tue, 19 Feb 2013 12:34:12 +0100 Message-ID: References: <1F9058DC-B7CF-4F8B-9329-D8F4FFEFE34E@berkeley.edu> <94C43798-051C-4A62-AD39-0B035A0CB8B6@nordsc.com> <51233975.3070309@gmx.de> In-Reply-To: <51233975.3070309@gmx.de> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: link-relations@ietf.org 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, 19 Feb 2013 11:34:13 -0000 * Julian Reschke wrote: >On 2013-02-19 09:21, Mike Kelly wrote: >> Consider it a synonym, then. If this is used in the wild it should be >> registered. > >If it used a *lot*, yes. Is it? It's been recommended for use in various settings as per the References in the proposed registration, http://xmlns.com/foaf/spec/#sec-autodesc would be another example, add http://www.w3.org/TR/cooluris/#linking and so on. As a consequence it is used a lot, yes. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From jan.algermissen@nordsc.com Tue Feb 19 03:52:32 2013 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 09F8D21F8B84 for ; Tue, 19 Feb 2013 03:52:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.944 X-Spam-Level: X-Spam-Status: No, score=-1.944 tagged_above=-999 required=5 tests=[AWL=0.305, 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 AHL+AyVE+pDU for ; Tue, 19 Feb 2013 03:52:21 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by ietfa.amsl.com (Postfix) with ESMTP id 2673821F8B6D for ; Tue, 19 Feb 2013 03:52:20 -0800 (PST) Received: from [192.168.2.103] (p548F9E5B.dip.t-dialin.net [84.143.158.91]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0Mbo1J-1UQ7PG0xM5-00J4Ss; Tue, 19 Feb 2013 12:52:15 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: 'meta' link relation From: Jan Algermissen In-Reply-To: <94F8694B-EB35-443B-BF25-0A5DE40B8236@gmail.com> Date: Tue, 19 Feb 2013 12:52:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <974550DF-E5E3-4EC1-95BF-C30D7301BE3D@nordsc.com> References: <1F9058DC-B7CF-4F8B-9329-D8F4FFEFE34E@berkeley.edu> <94C43798-051C-4A62-AD39-0B035A0CB8B6@nordsc.com> <94F8694B-EB35-443B-BF25-0A5DE40B8236@gmail.com> To: Ioseb Dzmanashvili X-Mailer: Apple Mail (2.1499) X-Provags-ID: V02:K0:ap5BjIEd5cgFZnBejh7RnDlNRKoQ783rE31cyojjcjv pKbzSj8cFZlFJqC+ME0cHkMFqmfItI6Ua7Zc0mIl8R9uWOpwnT xCKdyV/NrUdFKhQxBbPFg9MO12n7VZjRTSVIpBWaZqMz/w2tmq WD5XkN4H0aBwpFZX/WTtG6bQTUsqp9aoVgpRQNSA07hkIbcjZm pF5+Cl5bwZBctrgoDCxstjjXFWz43mkObuDDU87hoeuAPbVwp6 6WUbCesrWnW5CNPvVvdmiCkJDtn7AZ5kUYDdeel7fnCCWR/eXd dO85a0cggAh21IxAr7qTIyc2VW2t2lFvKHNlZLye6TR6uTJFdB tIEOBZReEnfi47ubaFjgdKDDf7WDPF6rmXLSox8MAB92346LkT /fTdogBJb9KOA== Cc: Bjoern Hoehrmann , "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, 19 Feb 2013 11:52:32 -0000 On 19.02.2013, at 12:07, Ioseb Dzmanashvili = wrote: > looks like i must accept "verdict" anyway :-) That's not the point. The point is that IMHO, your desire to have the rel is a symptom of = 'imperfect' design. Hence, I'd rather investigate than agree with any = rel that comes my way :-) Otherwise, we'd be pretty soon in 'gimme another method for my wanna-be = REST API' land overhere. Jan From julian.reschke@gmx.de Tue Feb 19 04:25:36 2013 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 2224221F8C17 for ; Tue, 19 Feb 2013 04:25:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.795 X-Spam-Level: X-Spam-Status: No, score=-104.795 tagged_above=-999 required=5 tests=[AWL=-2.196, 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 2-95QFge5MEi for ; Tue, 19 Feb 2013 04:25:35 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id D693A21F89FD for ; Tue, 19 Feb 2013 04:25:34 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.28]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MWvNq-1ULzDN3aKa-00VyOJ for ; Tue, 19 Feb 2013 13:25:33 +0100 Received: (qmail invoked by alias); 19 Feb 2013 12:25:33 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.102]) [217.91.35.233] by mail.gmx.net (mp028) with SMTP; 19 Feb 2013 13:25:33 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+Lp5tiAJqL2+Ws+NLMGM4FybTFPFSbof4zQyltuz 1V4heToLHnaZ8T Message-ID: <51236F3C.9070700@gmx.de> Date: Tue, 19 Feb 2013 13:25:32 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Bjoern Hoehrmann Subject: Re: 'meta' link relation References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: link-relations@ietf.org 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, 19 Feb 2013 12:25:36 -0000 On 2013-02-18 17:09, Bjoern Hoehrmann wrote: > Hi, > > I saw this on the Internet and thought I give this registration thing > a whirl... > > Relation Name: > meta > > Description: > Linked metadata. > > Reference: > http://tools.ietf.org/html/draft-daviel-metadata-link-00 Expired. > http://dublincore.org/documents/dcmes-xml/#sec4 Obsoleted by which doesn't mention it anymore. > http://www.w3.org/TR/rdf-syntax-grammar/#section-rdf-in-HTML Just a mention. So it seems that the definition we *could* use is , right? Should we then note that thos has been obsoleted, and that "describedby" is more current? Best regards, Julian From derhoermi@gmx.net Tue Feb 19 04:56:07 2013 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 D0F3821F8BB6 for ; Tue, 19 Feb 2013 04:56:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_REGSTR=2.3] 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 ViljSaFGD6LE for ; Tue, 19 Feb 2013 04:56:07 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id DC2A521F8B51 for ; Tue, 19 Feb 2013 04:56:06 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.10]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0M4EgP-1UxpCA0W15-00rsYo for ; Tue, 19 Feb 2013 13:56:05 +0100 Received: (qmail invoked by alias); 19 Feb 2013 12:56:04 -0000 Received: from p54B4E9AA.dip.t-dialin.net (EHLO netb.Speedport_W_700V) [84.180.233.170] by mail.gmx.net (mp010) with SMTP; 19 Feb 2013 13:56:04 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1/cnk94k0zc3oxNnHQZrEKbgNpFZexHpW4+7lztPP xJadOiTmKlvKiN From: Bjoern Hoehrmann To: Julian Reschke Subject: Re: 'meta' link relation Date: Tue, 19 Feb 2013 13:56:05 +0100 Message-ID: References: <51236F3C.9070700@gmx.de> In-Reply-To: <51236F3C.9070700@gmx.de> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: link-relations@ietf.org 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, 19 Feb 2013 12:56:07 -0000 * Julian Reschke wrote: >So it seems that the definition we *could* use is >, right? Should we then >note that thos has been obsoleted, and that "describedby" is more current? Referencing that document, or any other I've mentioned, is fine by me. I do not think it's useful to decide whether "describedby" is identical to "meta" and whether the latter is "obsolete" now. Problems here would be- gin with RFC 5988 saying "Refers to a resource providing information about the link's context." while the referenced document (and the regis- tration template the RFC uses is wrong, there is no Documentation field) has "The relationship A 'describedby' B asserts that resource B provides a description of resource A." and "provides information about" and "pro- vides a description of" is not quite the same thing. And if "meta" is obsolete, why does e.g. the FOAF specification not use "describedby" and why does the source code of http://www.dublincore.org/ still use "meta", and so on... -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From mca@amundsen.com Tue Feb 19 13:47:41 2013 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 C0B4A21F8AC0 for ; Tue, 19 Feb 2013 13:47:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.221 X-Spam-Level: X-Spam-Status: No, score=0.221 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FORGED_YAHOO_RCVD=2.297, HTML_MESSAGE=0.001, J_CHICKENPOX_38=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 10Eu77Ko4rWc for ; Tue, 19 Feb 2013 13:47:41 -0800 (PST) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by ietfa.amsl.com (Postfix) with ESMTP id AFD5021F8AAD for ; Tue, 19 Feb 2013 13:47:40 -0800 (PST) Received: by mail-wi0-f177.google.com with SMTP id hm14so5444294wib.16 for ; Tue, 19 Feb 2013 13:47:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:sender:from:date:x-google-sender-auth :message-id:subject:to:cc:content-type:x-gm-message-state; bh=H+ahFQLVtgtW+vvPae+UbBqPCa5witd9fZBYEvvGdo8=; b=D6siT9J5Lc/PTx+Zp/RF5tgCsuXUJpRJgA+niDInLirURxa08/Y0TmipH9FCUXS5r3 V5MaPCywmAmTe53TUIH8DUw2aE1a+lJUnpYV1pcHQJh4VT5kNrvtwOFGRRjxOAv6K6cy ip+EOM59aAf8B73DUWUtxcbNiLzvwoLM65f59L7Y7ougL5OSv9qnRZeM9zz9X+opeMEZ kFCJH2gfal9WFPs3fyXbnDRGefP06jXSk3PD1ou9WV/CbDYSXU64FxnOMioDq+P5n5cp PYFABA28MPbM2NOCicjPCRoch63yEu4/FaCW/2DcH0uw0InJl7u9Itaqu80yjoPyfvMc H83g== X-Received: by 10.194.108.229 with SMTP id hn5mr29719756wjb.8.1361310459624; Tue, 19 Feb 2013 13:47:39 -0800 (PST) MIME-Version: 1.0 Sender: mca@amundsen.com Received: by 10.194.119.201 with HTTP; Tue, 19 Feb 2013 13:47:19 -0800 (PST) From: mike amundsen Date: Tue, 19 Feb 2013 16:47:19 -0500 X-Google-Sender-Auth: tlWYw8AQm9jgaXrcKUrTZsTfJXc Message-ID: Subject: Status of "profile" and IANA Link Relations list To: link-relations Content-Type: multipart/alternative; boundary=047d7bf198905ffcff04d61acaf0 X-Gm-Message-State: ALoCoQnpjWFSLV9fObZCc9Qo/XHxALmkNWes/PmHBkOxiXJ95jcShhhFlDr3dql9YTMni9dCdaNs 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, 19 Feb 2013 21:47:42 -0000 --047d7bf198905ffcff04d61acaf0 Content-Type: text/plain; charset=ISO-8859-1 What's the status of the "profile" LR[1]? Any chance we can get this added to the IANA list right now? I see some added here that are still in I-D status (e.g. type, terms-of-service, etc)[2] [1] https://datatracker.ietf.org/doc/draft-wilde-profile-link/ [2] http://tools.ietf.org/html/draft-snell-additional-link-relations-07 mamund +1.859.757.1449 skype: mca.amundsen http://amundsen.com/blog/ http://twitter.com/mamund https://github.com/mamund http://www.linkedin.com/in/mikeamundsen --047d7bf198905ffcff04d61acaf0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable What's the status of the "profile" LR[1]?

= Any chance we can get this added to the IANA list right now? I see some add= ed here that are still in I-D status (e.g. type, terms-of-service, etc)[2]<= /div>



--047d7bf198905ffcff04d61acaf0-- From ioseb.dzmanashvili@gmail.com Tue Feb 19 13:54:27 2013 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 CAA7221E805E for ; Tue, 19 Feb 2013 13:54:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.412, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_38=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 HJVj2w3jhhmC for ; Tue, 19 Feb 2013 13:54:23 -0800 (PST) Received: from mail-ea0-f181.google.com (mail-ea0-f181.google.com [209.85.215.181]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB7C21E8050 for ; Tue, 19 Feb 2013 13:54:22 -0800 (PST) Received: by mail-ea0-f181.google.com with SMTP id i13so3011403eaa.26 for ; Tue, 19 Feb 2013 13:54:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:message-id:in-reply-to:references :subject:x-mailer:mime-version:content-type; bh=NW7goOIntkgUE3/YbM19O4zfpWruPn3jDeSdOMnZroI=; b=H6h8tIlmgBre63HghNrfPzexNjhEgXKupGOZrI9ius9xeUhF15auzClo/qwOJpq1XD 9909pfAQsU1qEYbh0FHvwvcNpwsaKw9nfOdxkmrqQKYHUgqwtuD67H2uy38Uq/p7sLLH E3y4GMhDWeEwFoPp8NxleRfUCuDns3/plym/o2RCQIO0rcQROX1iJ5ppo/1LKaNEfznh kDcMKR+GmIOSIXfnErJjRAe0oMCpRYtoVRicq2Sedp+kY/x+lfOfRf/J6lNPEtkKyu1/ OcGaSAjBlBNBSTUIdEGI+n/xU4JZlf64MBWUN7wJpGfOla0qTck/vR2PERZw6LuSyC57 oB+A== X-Received: by 10.14.0.135 with SMTP id 7mr61142366eeb.5.1361310861568; Tue, 19 Feb 2013 13:54:21 -0800 (PST) Received: from [192.168.1.10] ([176.73.174.236]) by mx.google.com with ESMTPS id a1sm80758941eep.2.2013.02.19.13.54.19 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 19 Feb 2013 13:54:20 -0800 (PST) Date: Wed, 20 Feb 2013 01:54:17 +0400 From: Ioseb Dzmanashvili To: mike amundsen Message-ID: In-Reply-To: References: Subject: Re: Status of "profile" and IANA Link Relations list X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5123f489_706b674e_19c" Cc: link-relations 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, 19 Feb 2013 21:54:27 -0000 X-List-Received-Date: Tue, 19 Feb 2013 21:54:27 -0000 --5123f489_706b674e_19c Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Mike, I see "profile" link in the IANA list. It's right above "related" link relation[1]. Maybe cache? [1]. http://www.iana.org/assignments/link-relations/link-relations.xml Cheers, ioseb On Wednesday, February 20, 2013 at 1:47 AM, mike amundsen wrote: > What's the status of the "profile" LR[1]? > > Any chance we can get this added to the IANA list right now? I see some added here that are still in I-D status (e.g. type, terms-of-service, etc)[2] > > > [1] https://datatracker.ietf.org/doc/draft-wilde-profile-link/ > [2] http://tools.ietf.org/html/draft-snell-additional-link-relations-07 > > > mamund > +1.859.757.1449 > skype: mca.amundsen > http://amundsen.com/blog/ > http://twitter.com/mamund > https://github.com/mamund > http://www.linkedin.com/in/mikeamundsen > _______________________________________________ > link-relations mailing list > link-relations@ietf.org (mailto:link-relations@ietf.org) > https://www.ietf.org/mailman/listinfo/link-relations > > > --5123f489_706b674e_19c Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Mike,

I see =22profile=22= link in the IANA list. It's right above =22related=22 link relation=5B1=5D= . Maybe cache=3F

<= br>
Cheers,
ioseb
=20

On Wednesday, =46ebrua= ry 20, 2013 at 1:47 AM, mike amundsen wrote:

=20 =20 =20 =20

--5123f489_706b674e_19c-- From mca@amundsen.com Tue Feb 19 13:56:25 2013 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 BF03E21E8050 for ; Tue, 19 Feb 2013 13:56:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.82 X-Spam-Level: * X-Spam-Status: No, score=1.82 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FORGED_YAHOO_RCVD=2.297, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, NO_RELAYS=-0.001] 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 JB6RWLpFB-x7 for ; Tue, 19 Feb 2013 13:56:24 -0800 (PST) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id B298521F87D7 for ; Tue, 19 Feb 2013 13:56:22 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id p43so4197254wea.38 for ; Tue, 19 Feb 2013 13:56:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :x-gm-message-state; bh=HSE5ulVL6h4IXx1xlPw8hV0rqkH+DxzsQoGE6rFcPiI=; b=KAVrk6yODnnY3BDiRdTpEd1X7n4U6c09BIAxcxxcJGa7dqic7UKvmteDKxswbe0lz2 bRBlU46q8PQOlWuY7f2/WkHzMUaX+aXmUXBmtGl0gGjiaQVKr8i+6AxVuE9J5Q0FnlRc EGGlz4zZ76bg9kMnPDWwWqBNoEnV0fE2OterAHOWZe41S8TuacFDxN5zEeLpp7VeMbXk LMINgbZnrwEVZ9tnBcyQ8na23uX+rypGI+2GzmIEUwEN8pMn88kGiJKEHDUwVSn+ZeHz 1afoHBqjR7hZBvX8C41uAFYjKA08C3MaeswuaBOIICWpMnrpUe/H1SpMKdeuxjhx8yAe 4Idw== X-Received: by 10.194.76.37 with SMTP id h5mr29876611wjw.21.1361310981694; Tue, 19 Feb 2013 13:56:21 -0800 (PST) MIME-Version: 1.0 Sender: mca@amundsen.com Received: by 10.194.119.201 with HTTP; Tue, 19 Feb 2013 13:56:01 -0800 (PST) In-Reply-To: References: From: mike amundsen Date: Tue, 19 Feb 2013 16:56:01 -0500 X-Google-Sender-Auth: XUVexvXwv2XFDcbA1CJgCqRuBqs Message-ID: Subject: Re: Status of "profile" and IANA Link Relations list To: Ioseb Dzmanashvili Content-Type: multipart/alternative; boundary=047d7bb03bc47e23b204d61ae986 X-Gm-Message-State: ALoCoQnJk/IYGAQ7VTJ+M8CSmPhwtnVWp/KTmOVt32eWySirgHu4QSGC8tfWbncG0cHSqswTAOWC Cc: link-relations 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, 19 Feb 2013 21:56:26 -0000 --047d7bb03bc47e23b204d61ae986 Content-Type: text/plain; charset=ISO-8859-1 ack! yep, already listed. sorry for missing that. still interested in RFC progress. thanks for the catch Ioseb. mamund +1.859.757.1449 skype: mca.amundsen http://amundsen.com/blog/ http://twitter.com/mamund https://github.com/mamund http://www.linkedin.com/in/mikeamundsen On Tue, Feb 19, 2013 at 4:54 PM, Ioseb Dzmanashvili < ioseb.dzmanashvili@gmail.com> wrote: > Hi Mike, > > I see "profile" link in the IANA list. It's right above "related" link > relation[1]. Maybe cache? > > [1]. http://www.iana.org/assignments/link-relations/link-relations.xml > > Cheers, > ioseb > > On Wednesday, February 20, 2013 at 1:47 AM, mike amundsen wrote: > > What's the status of the "profile" LR[1]? > > Any chance we can get this added to the IANA list right now? I see some > added here that are still in I-D status (e.g. type, terms-of-service, > etc)[2] > > > [1] https://datatracker.ietf.org/doc/draft-wilde-profile-link/ > [2] http://tools.ietf.org/html/draft-snell-additional-link-relations-07 > > > mamund > +1.859.757.1449 > skype: mca.amundsen > http://amundsen.com/blog/ > http://twitter.com/mamund > https://github.com/mamund > http://www.linkedin.com/in/mikeamundsen > _______________________________________________ > link-relations mailing list > link-relations@ietf.org > https://www.ietf.org/mailman/listinfo/link-relations > > > --047d7bb03bc47e23b204d61ae986 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable ack!

yep, already listed. sorry for missing that.
<= div>
still interested in RFC progress.

thanks for the catch Ioseb.



On Tue, Feb 19, 2013 at 4:54 PM, Ioseb D= zmanashvili <ioseb.dzmanashvili@gmail.com> wrote:=
Hi Mike,

I see "profile&= quot; link in the IANA list. It's right above "related" link = relation[1]. Maybe cache?

[1].=A0http://www.iana.org/assignments/link-relations/link-relations.xml

Cheers,
ioseb
=20

On Wednesday, February 20, 2013 = at 1:47 AM, mike amundsen wrote:

<= div>
What's the s= tatus of the "profile" LR[1]?

Any chance we ca= n get this added to the IANA list right now? I see some added here that are= still in I-D status (e.g. type, terms-of-service, etc)[2]



_______________________________________________=
link-relations mailing list
https://www.ietf.org/mailman/listinfo/link-relations
 =20 =20 =20 =20


--047d7bb03bc47e23b204d61ae986-- From ioseb.dzmanashvili@gmail.com Tue Feb 19 14:04:01 2013 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 D691321E808E for ; Tue, 19 Feb 2013 14:04:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.909 X-Spam-Level: X-Spam-Status: No, score=-2.909 tagged_above=-999 required=5 tests=[AWL=0.689, 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 5yYm6gNwV6wi for ; Tue, 19 Feb 2013 14:03:49 -0800 (PST) Received: from mail-ee0-f43.google.com (mail-ee0-f43.google.com [74.125.83.43]) by ietfa.amsl.com (Postfix) with ESMTP id 70FC021F89A3 for ; Tue, 19 Feb 2013 14:03:47 -0800 (PST) Received: by mail-ee0-f43.google.com with SMTP id c50so3623031eek.30 for ; Tue, 19 Feb 2013 14:03:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:message-id:in-reply-to:references :subject:x-mailer:mime-version:content-type; bh=CnfSQyniNnIhQ/5g+rjEGuc0xf/RrGPFFOtuPOrnCjE=; b=w7jX7yb1qou2IL9VdRzl8G/3evpEdzvAuIReS72tVIMwpmkcY5mFq5dcPfBkt1arhk aqi1xtzqcrGyuy1oSuve3THf18cYjJgPZ1yS/SYKWoEhw8+00c50CZAwRnF4xMWDnUE1 4wUfR6NJUWVRXlPOM+X/PWJFjB65rBu+lR8v4rFeuZkLWyDs23NCB07xZ0fnUC4UPcBT sv/71N7ZuFLxtuWGB+d6zwQ/lW0deAatjreqDanxvnCccq/bXCLIHfwDx9+5ken8jjr4 xZjd5DrhVbbRZ3hzEABFwRHlzlHCjnJdEiTnXX+vLjybIvttLTA1uAykwa3O0MhOQnw3 Sw1Q== X-Received: by 10.14.219.129 with SMTP id m1mr61176833eep.16.1361311426005; Tue, 19 Feb 2013 14:03:46 -0800 (PST) Received: from [192.168.1.10] ([176.73.174.236]) by mx.google.com with ESMTPS id 3sm106084052eej.6.2013.02.19.14.03.43 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 19 Feb 2013 14:03:44 -0800 (PST) Date: Wed, 20 Feb 2013 02:03:41 +0400 From: Ioseb Dzmanashvili To: Jan Algermissen Message-ID: In-Reply-To: <974550DF-E5E3-4EC1-95BF-C30D7301BE3D@nordsc.com> References: <1F9058DC-B7CF-4F8B-9329-D8F4FFEFE34E@berkeley.edu> <94C43798-051C-4A62-AD39-0B035A0CB8B6@nordsc.com> <94F8694B-EB35-443B-BF25-0A5DE40B8236@gmail.com> <974550DF-E5E3-4EC1-95BF-C30D7301BE3D@nordsc.com> Subject: Re: 'meta' link relation X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5123f6bd_1d91467c_19c" Cc: "=?utf-8?Q?link-relations=40ietf.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, 19 Feb 2013 22:04:01 -0000 X-List-Received-Date: Tue, 19 Feb 2013 22:04:01 -0000 --5123f6bd_1d91467c_19c Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Tuesday, February 19, 2013 at 3:52 PM, Jan Algermissen wrote: > > On 19.02.2013, at 12:07, Ioseb Dzmanashvili wrote: > > > looks like i must accept "verdict" anyway :-) > > That's not the point. > > The point is that IMHO, your desire to have the rel is a symptom of 'imperfect' design. Hence, I'd rather investigate than agree with any rel that comes my way :-) Perfection is relative :-) > > Otherwise, we'd be pretty soon in 'gimme another method for my wanna-be REST API' land overhere. Fair enough. > > Jan Sorry for off top again. ioseb --5123f6bd_1d91467c_19c Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
On T= uesday, =46ebruary 19, 2013 at 3:52 PM, Jan Algermissen wrote:

On 19.02.2013, at= 12:07, Ioseb Dzmanashvili <ioseb.dzmanashvili=40gmail.com> wrote:

<= /div>
looks like i must accept =22verdi= ct=22 anyway :-)

That's not the poi= nt.

The point is that IMHO, your desire to have = the rel is a symptom of 'imperfect' design. Hence, I'd rather investigate= than agree with any rel that comes my way :-)
Perfection is relative :-)

Otherwise, we'd= be pretty soon in 'gimme another method for my wanna-be REST API' land o= verhere.
=46air enough.

Jan
Sorry for off top a= gain.
 
=20
ioseb
--5123f6bd_1d91467c_19c-- From dret@berkeley.edu Wed Feb 20 00:01:30 2013 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 36BD821F89B5 for ; Wed, 20 Feb 2013 00:01:30 -0800 (PST) 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 ujKbxYp7iJxr for ; Wed, 20 Feb 2013 00:01:29 -0800 (PST) Received: from cm06fe.IST.Berkeley.EDU (cm06fe.IST.Berkeley.EDU [169.229.218.147]) by ietfa.amsl.com (Postfix) with ESMTP id C31A321F893E for ; Wed, 20 Feb 2013 00:01:29 -0800 (PST) Received: from 46-126-158-51.dynamic.hispeed.ch ([46.126.158.51] helo=dretpro.local) by cm06fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1U84cK-00032u-Jg; Wed, 20 Feb 2013 00:01:29 -0800 Message-ID: <512482D3.5020908@berkeley.edu> Date: Wed, 20 Feb 2013 09:01:23 +0100 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: mike amundsen Subject: Re: Status of "profile" and IANA Link Relations list References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: link-relations 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, 20 Feb 2013 08:01:30 -0000 hello mike. On 2013-02-19 22:56 , mike amundsen wrote: > yep, already listed. sorry for missing that. > still interested in RFC progress. hard to tell. it has been sitting in the RFC editor queue [1] for a while, and afaict, getting out of this queue is an indeterministic process, simply based on workload and capacity of the RFC editor. i have no idea how long it is going to take until RFChood is achieved, but i hope it is not going to be more than a couple of weeks. fwiw, i had completed working on this draft mid-october, and since then it has been moving along according to the process. cheers, dret. [1] http://www.rfc-editor.org/queue.html From julian.reschke@gmx.de Wed Feb 20 00:22:45 2013 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 67D2D21F8AE8 for ; Wed, 20 Feb 2013 00:22:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.067 X-Spam-Level: X-Spam-Status: No, score=-106.067 tagged_above=-999 required=5 tests=[AWL=-3.468, 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 oG9JkpJROw9i for ; Wed, 20 Feb 2013 00:22:38 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id F0DB221F883A for ; Wed, 20 Feb 2013 00:22:37 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.33]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0Lpzc9-1UlGzD1xmJ-00fhIX for ; Wed, 20 Feb 2013 09:22:36 +0100 Received: (qmail invoked by alias); 20 Feb 2013 08:22:36 -0000 Received: from p5DD9723A.dip.t-dialin.net (EHLO [192.168.1.102]) [93.217.114.58] by mail.gmx.net (mp033) with SMTP; 20 Feb 2013 09:22:36 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18tgGIbG/stKHL0OtLh1ysy38CPPZYpUXSG4cz1RU Q50gWQdKumusr/ Message-ID: <512487CA.7050800@gmx.de> Date: Wed, 20 Feb 2013 09:22:34 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Erik Wilde Subject: Re: Status of "profile" and IANA Link Relations list References: <512482D3.5020908@berkeley.edu> In-Reply-To: <512482D3.5020908@berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: link-relations 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, 20 Feb 2013 08:22:45 -0000 On 2013-02-20 09:01, Erik Wilde wrote: > hello mike. > > On 2013-02-19 22:56 , mike amundsen wrote: >> yep, already listed. sorry for missing that. >> still interested in RFC progress. > > hard to tell. it has been sitting in the RFC editor queue [1] for a > while, and afaict, getting out of this queue is an indeterministic > process, simply based on workload and capacity of the RFC editor. i have It's a queue. It's not *that* indeterministic. Usually, it shouldn't take more than two months. > ... Best regards, Julian From mca@amundsen.com Wed Feb 20 07:13:13 2013 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 A9CBA21F886B for ; Wed, 20 Feb 2013 07:13:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.221 X-Spam-Level: X-Spam-Status: No, score=0.221 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FORGED_YAHOO_RCVD=2.297, HTML_MESSAGE=0.001, J_CHICKENPOX_38=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 tBbKGRmJamgB for ; Wed, 20 Feb 2013 07:13:13 -0800 (PST) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by ietfa.amsl.com (Postfix) with ESMTP id A53E321F8821 for ; Wed, 20 Feb 2013 07:13:12 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id 15so6371252wgd.4 for ; Wed, 20 Feb 2013 07:13:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :x-gm-message-state; bh=XvD+XNxOqa0RNr6VSrujo86Rp48m8TTBz12kayL8hTM=; b=khaNOxguBAbo3g7LgTkdoUVHrsT9eM0/XMnhOo+98O3HwgmfCGCExftvaf8N9eZ+9p eCMfJiuG9B9KK4BOqts4Mf+9GTKPo3786A0/p0cFCs6AkYkUxAvVmzPK5wZXC2vGzQgx zZPKUfGRZD6s+NdN4RolRJZTms8WYzPyCj5BeIbSjfNxAwTPubzPzlD0JkewIyHtR4+d b8ZnpA/mZB4e1filQTJ56JKoa33vbwcBXreiA9j4/5o2N2Ue0X6tEgv3992lipb6DtrN 2wNDw84UB6NWFG0M2MVGJPKDHnYk0jchDZWOdpEhQlwL/VIpOma0G7kbp/vw+3N+gSzo CHvg== X-Received: by 10.194.76.37 with SMTP id h5mr34810495wjw.21.1361373189297; Wed, 20 Feb 2013 07:13:09 -0800 (PST) MIME-Version: 1.0 Sender: mca@amundsen.com Received: by 10.194.119.201 with HTTP; Wed, 20 Feb 2013 07:12:49 -0800 (PST) In-Reply-To: <512487CA.7050800@gmx.de> References: <512482D3.5020908@berkeley.edu> <512487CA.7050800@gmx.de> From: mike amundsen Date: Wed, 20 Feb 2013 10:12:49 -0500 X-Google-Sender-Auth: bdWODk23viyH45SKKFGW0Z-iU14 Message-ID: Subject: Re: Status of "profile" and IANA Link Relations list To: Julian Reschke Content-Type: multipart/alternative; boundary=047d7bb03bc45ad66a04d6296579 X-Gm-Message-State: ALoCoQkxvR+fXJkGbgxU1S3AwKAVcXQ9SokoZ9ROmQkLLn5rebbN/9j74VmD0WW3yY9wQR7lZJAb Cc: link-relations 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, 20 Feb 2013 15:13:13 -0000 --047d7bb03bc45ad66a04d6296579 Content-Type: text/plain; charset=ISO-8859-1 AFAICT, the "profile" link rel draft text has remained unchanged for four months. Just seemed unusual for this one. Thanks for the update and looking forward to seeing it finally hit RFC-world :) Cheers. mamund +1.859.757.1449 skype: mca.amundsen http://amundsen.com/blog/ http://twitter.com/mamund https://github.com/mamund http://www.linkedin.com/in/mikeamundsen On Wed, Feb 20, 2013 at 3:22 AM, Julian Reschke wrote: > On 2013-02-20 09:01, Erik Wilde wrote: > >> hello mike. >> >> On 2013-02-19 22:56 , mike amundsen wrote: >> >>> yep, already listed. sorry for missing that. >>> still interested in RFC progress. >>> >> >> hard to tell. it has been sitting in the RFC editor queue [1] for a >> while, and afaict, getting out of this queue is an indeterministic >> process, simply based on workload and capacity of the RFC editor. i have >> > > It's a queue. It's not *that* indeterministic. Usually, it shouldn't take > more than two months. > > ... >> > > Best regards, Julian > --047d7bb03bc45ad66a04d6296579 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable AFAICT, the "profile" link rel draft text has=A0remained=A0unchan= ged for four months.

Just seemed unusual for this one.

Thanks for the update and looking forward to seeing= it finally hit RFC-world :)

Cheers.



On Wed, Feb 20, 2013 at 3:22 AM, Julian = Reschke <julian.reschke@gmx.de> wrote:
On 2013-02-20 09:01, Erik Wilde wrote:
hello mike.

On 2013-02-19 22:56 , mike amundsen wrote:
yep, already listed. sorry for missing that.
still interested in RFC progress.

hard to tell. it has been sitting in the RFC editor queue [1] for a
while, and afaict, getting out of this queue is an indeterministic
process, simply based on workload and capacity of the RFC editor. i have

It's a queue. It's not *that* indeterministic. Usually, it shouldn&= #39;t take more than two months.

...

Best regards, Julian

--047d7bb03bc45ad66a04d6296579-- From dret@berkeley.edu Wed Feb 20 07:23:49 2013 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 8293221F86CC for ; Wed, 20 Feb 2013 07:23:49 -0800 (PST) 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.000, 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 S7WumZ1IEn8Q for ; Wed, 20 Feb 2013 07:23:48 -0800 (PST) Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) by ietfa.amsl.com (Postfix) with ESMTP id EC0C221F86C3 for ; Wed, 20 Feb 2013 07:23:48 -0800 (PST) Received: from 46-126-158-51.dynamic.hispeed.ch ([46.126.158.51] helo=dretpro.local) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1U8BWK-0002cP-CC; Wed, 20 Feb 2013 07:23:48 -0800 Message-ID: <5124EA7C.5050505@berkeley.edu> Date: Wed, 20 Feb 2013 16:23:40 +0100 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: mike amundsen Subject: Re: Status of "profile" and IANA Link Relations list References: <512482D3.5020908@berkeley.edu> <512487CA.7050800@gmx.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: link-relations 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, 20 Feb 2013 15:23:49 -0000 hello mike. On 2013-02-20 16:12 , mike amundsen wrote: > AFAICT, the "profile" link rel draft text has remained unchanged for > four months. Just seemed unusual for this one. yes, that's true. that's when the last draft (-04) was published. > Thanks for the update and looking forward to seeing it finally hit > RFC-world :) in case you're curious, https://github.com/dret/I-D/tree/master/profile-link has an (unpublished) -05 which contains the minor edits that i've made to -04, but there really are only editorial changes. cheers, dret. From julian.reschke@gmx.de Wed Feb 20 07:24:28 2013 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 5FD4121F8836 for ; Wed, 20 Feb 2013 07:24:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.836 X-Spam-Level: X-Spam-Status: No, score=-104.836 tagged_above=-999 required=5 tests=[AWL=-2.237, 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 brk1ruVCDxYV for ; Wed, 20 Feb 2013 07:24:27 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 981EA21F87FF for ; Wed, 20 Feb 2013 07:24:27 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.30]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0Lgszg-1UcHPw2cXm-00oGvW for ; Wed, 20 Feb 2013 16:24:26 +0100 Received: (qmail invoked by alias); 20 Feb 2013 15:24:26 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.102]) [217.91.35.233] by mail.gmx.net (mp030) with SMTP; 20 Feb 2013 16:24:26 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX190+zJbEep0t64cX8hGFsYAonDrT+OzQS1YHebg+k Knb0un8sEL47/0 Message-ID: <5124EAA7.1000202@gmx.de> Date: Wed, 20 Feb 2013 16:24:23 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: mike amundsen Subject: Re: Status of "profile" and IANA Link Relations list References: <512482D3.5020908@berkeley.edu> <512487CA.7050800@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: link-relations 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, 20 Feb 2013 15:24:28 -0000 On 2013-02-20 16:12, mike amundsen wrote: > AFAICT, the "profile" link rel draft text has remained unchanged for > four months. > > Just seemed unusual for this one. > ... It has been sent to the RFC Editor just two weeks ago, see . Best regards, Julian From mca@amundsen.com Wed Feb 20 07:28:36 2013 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 C9CAC21F872C for ; Wed, 20 Feb 2013 07:28:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.121 X-Spam-Level: X-Spam-Status: No, score=0.121 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FORGED_YAHOO_RCVD=2.297, HTML_MESSAGE=0.001, J_CHICKENPOX_38=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 Yzy1VZeE2Wq0 for ; Wed, 20 Feb 2013 07:28:35 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id A10C921F8718 for ; Wed, 20 Feb 2013 07:28:35 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id ez12so6320879wid.11 for ; Wed, 20 Feb 2013 07:28:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :x-gm-message-state; bh=+ZoHv0dbg+nXoMtQi8tuU+vg1GLbqRLy9InYI+oH+74=; b=fW3S9S2fq1GeNHH6vko4olFB2wM6fwCzISBXc8w40Z8kk9MQ9QcG6xX7CLxcHiAdv2 12K732jJO0XBQjxRspBpPjfTZ1J6S90c6BKxhjB4emZhPCrwfqA/1wjHJt0NoOEQMq37 qEeiMx9w/9sctIj2LSxDDGIlwVgPTHGmRu/GWzLg2tglB6t4keMDanQ5uLsomzoKoPTA vCNJuMvYoob9Y0w3kjWC448NU6H7XwkIckSJQOdCkEPgRV8kGyFCpym/R9lcfRGQJmsN CMXxeIlBrpEE8N22S05z1TG3c/WAmvF3tenrB903K42mUYsniAQNGIIp6oHckuwsqske B1zA== X-Received: by 10.180.94.69 with SMTP id da5mr35126046wib.30.1361374114836; Wed, 20 Feb 2013 07:28:34 -0800 (PST) MIME-Version: 1.0 Sender: mca@amundsen.com Received: by 10.194.119.201 with HTTP; Wed, 20 Feb 2013 07:28:14 -0800 (PST) In-Reply-To: <5124EAA7.1000202@gmx.de> References: <512482D3.5020908@berkeley.edu> <512487CA.7050800@gmx.de> <5124EAA7.1000202@gmx.de> From: mike amundsen Date: Wed, 20 Feb 2013 10:28:14 -0500 X-Google-Sender-Auth: g-5O2PgWjZxetNWoMTgUU726F1g Message-ID: Subject: Re: Status of "profile" and IANA Link Relations list To: Julian Reschke Content-Type: multipart/alternative; boundary=f46d0442694a85724c04d6299c85 X-Gm-Message-State: ALoCoQld1ZcuDhELKug8riEYpyW/gtLVFfeLniKIaNPBJxRCGBusXJi567vV4UaoFIwtx8X/zwod Cc: link-relations 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, 20 Feb 2013 15:28:36 -0000 --f46d0442694a85724c04d6299c85 Content-Type: text/plain; charset=ISO-8859-1 all cool. thanks for the follow ups. cheers. mamund +1.859.757.1449 skype: mca.amundsen http://amundsen.com/blog/ http://twitter.com/mamund https://github.com/mamund http://www.linkedin.com/in/mikeamundsen On Wed, Feb 20, 2013 at 10:24 AM, Julian Reschke wrote: > On 2013-02-20 16:12, mike amundsen wrote: > >> AFAICT, the "profile" link rel draft text has remained unchanged for >> four months. >> >> Just seemed unusual for this one. >> ... >> > > > It has been sent to the RFC Editor just two weeks ago, see < > https://datatracker.ietf.org/**doc/draft-wilde-profile-link/**history/ > >. > > Best regards, Julian > --f46d0442694a85724c04d6299c85 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable all cool.

thanks for the follow ups.

cheers.



On Wed, Feb 20, 2013 at 10:24 AM, Julian= Reschke <julian.reschke@gmx.de> wrote:
On 2013-02-20 16:12, mike amundsen wrote:
AFAICT, the "profile" link rel draft text has remained unchanged = for
four months.

Just seemed unusual for this one.
...


It has been sent to the RFC Editor just two weeks ago, see <https://datatracker.ietf.org/doc/draft-wilde-profile-lin= k/history/>.

Best regards, Julian

--f46d0442694a85724c04d6299c85--