Subject: [apps-discuss] Fwd: New Version Notification for draft-hamnaberg-publish-link-relation-00.txt

From: Erlend Hamnaberg <[email-masked]>
Date: Wed, 15 Jan 2014 15:08:31 +0100

My first Internet Draft, please be nice =)

Please give feedback.

Not sure if this is the correct mailing list to send this to.

Please let me know if I should send it somewhere else.

Yours,

Erlend

---------- Forwarded message ----------
From: <[email-masked]>
Date: Wed, Jan 15, 2014 at 3:05 PM
Subject: New Version Notification for
draft-hamnaberg-publish-link-relation-00.txt
To: Erlend Hamnaberg <[email-masked]>

A new version of I-D, draft-hamnaberg-publish-link-relation-00.txt
has been successfully submitted by Erlend Hamnaberg and posted to the
IETF repository.

Name:           draft-hamnaberg-publish-link-relation
Revision:       00
Title:          The 'publish' Link Relation Type
Document date:  2014-01-15
Group:          Individual Submission
Pages:          6
URL:
http://www.ietf.org/internet-drafts/draft-hamnaberg-publish-link-relation-00.txt
Status:
https://datatracker.ietf.org/doc/draft-hamnaberg-publish-link-relation/
Htmlized:
http://tools.ietf.org/html/draft-hamnaberg-publish-link-relation-00

Abstract:
   This memo defines a 'publish' link relation and provides a number of
   examples.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Darrel Miller <[email-masked]>
Date: Wed, 15 Jan 2014 09:18:45 -0500

Hi Erlend,

I think this is an excellent idea.  Do you think it would be worth
suggesting that the Location header be set in the response to identify
the location of the "published resource"?  Can we assume that "to
publish" means to publish on the internet and that the result is
itself a resource with a URI?  Or is that an unnecessary restriction?

Darrel

On Wed, Jan 15, 2014 at 9:08 AM, Erlend Hamnaberg <[email-masked]> wrote:
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Erlend Hamnaberg <[email-masked]>
Date: Wed, 15 Jan 2014 15:25:09 +0100

Perhaps.

On Wed, Jan 15, 2014 at 3:18 PM, Darrel Miller <[email-masked]>wrote:

> Hi Erlend,
>
> I think this is an excellent idea.

Thanks.

>  Do you think it would be worth
> the location of the "published resource"?

Perhaps.
That works only when you publish a single resource, and not a collection of
resources.

I was thinking that the application is defining what publishing means.
You may, for instance, still be required to log in, but now the resource
has become immutable.

> Can we assume that "to
> itself a resource with a URI?

Or is that an unnecessary restriction?

That would mean that you can only publish single resources yes?

--
Erlend

---

From: Darrel Miller <[email-masked]>
Date: Wed, 15 Jan 2014 09:45:00 -0500

I was assuming that a publish link would use the target URI to publish
the resource at the context URI.  If the context URI happens to
contain links to a set of resources, then the publish processor could
publish that set of resources.

>From your response I take you are seeing this more as service where
you pass some kind of reference/list/collection and the service
publishes resource based on the content of the passed body?   I'm not
sure the two approaches are mutually exclusive, but you are correct
that Location header wouldn't be very useful in the second case.

Darrel

On Wed, Jan 15, 2014 at 9:25 AM, Erlend Hamnaberg <[email-masked]> wrote:
> You may, for instance, still be required to log in, but now the resource has
> become immutable.
>
>>
>> Can we assume that "to

---

From: Erlend Hamnaberg <[email-masked]>
Date: Wed, 15 Jan 2014 16:24:13 +0100

On Wed, Jan 15, 2014 at 3:45 PM, Darrel Miller <[email-masked]>wrote:

> Both are viable options. The server decides.
There must be a way to communicate the context uri to the target uri.
There are multiple options here.

1) Link header:

Link: <http://example.com/1234>; rel=self

2) text/uri-list in body
http://example.com/1234\r\n

3) HTML Form in body
source=http://example.com/1234

4) Abuse of the Referer header.

LINK method
Can be used with (1).

POST method
Can be used with (1,2,3).

> publishes resource based on the content of the passed body?

This is one of the possible uses yes.

> I'm not

You are correct that the two approaches are not mutually exclusive.
I am not sure if this link relations should specify _how_ the publishing is
done, this should be implementation specific.

--
Erlend

---

From: "Rushforth, Peter" <[email-masked]>
Date: Wed, 15 Jan 2014 15:26:36 +0000

Erlend,

I think the publish link relation might be useful in the context of AtomPub, but I think that putting the text/uri-list media type in the app:accept list per your draft is a different meaning from AtomPub, where the list of media types is of types that can be POSTed to the feed as media entries.  Ie it specifies what happens generically not based on media type.  Perhaps specifying an app:collection/atom:link[@rel='publish'][@type='text/uri-list']  would be the right approach?  Not sure about the @type value, since in my understanding the @type advertises what media type should be negoiated with the server, not what should be POSTed.  But perhaps narrowing the scope of the link to app:collection would alleviate that?

Cheers,
Peter

From: apps-discuss [mailto:[email-masked]] On Behalf Of Erlend Hamnaberg
Sent: January 15, 2014 09:09
To: [email-masked]
Subject: [apps-discuss] Fwd: New Version Notification for draft-hamnaberg-publish-link-relation-00.txt

Please give feedback.

Yours,

Erlend
---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Wed, Jan 15, 2014 at 3:05 PM
Subject: New Version Notification for draft-hamnaberg-publish-link-relation-00.txt
To: Erlend Hamnaberg <[email-masked]<mailto:[email-masked]>>

Name:           draft-hamnaberg-publish-link-relation
Revision:       00
Title:          The 'publish' Link Relation Type
Document date:  2014-01-15
Group:          Individual Submission
Pages:          6
URL:            http://www.ietf.org/internet-drafts/draft-hamnaberg-publish-link-relation-00.txt
Status:         https://datatracker.ietf.org/doc/draft-hamnaberg-publish-link-relation/
Htmlized:       http://tools.ietf.org/html/draft-hamnaberg-publish-link-relation-00

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat

---

From: Erlend Hamnaberg <[email-masked]>
Date: Wed, 15 Jan 2014 16:39:21 +0100

Peter.

On Wed, Jan 15, 2014 at 4:26 PM, Rushforth, Peter <
[email-masked]> wrote:

>  Erlend,
>
>
>
> I think the publish link relation might be useful in the context of
> AtomPub, but I think that putting the text/uri-list media type in the
> app:accept list per your draft is a different meaning from AtomPub, where
> the list of media types is of types that can be POSTed to the feed as media
> entries.  Ie it specifies what happens generically not based on media
> type.
>

Atompub is just one format where this is useful. I have used a similar
approach with for instance collection+json.

Right. My understanding of atompub is probably flawed.

> Perhaps specifying an
> app:collection/atom:link[@rel=’publish’][@type=’text/uri-list’]  would be
> the right approach?  Not sure about the @type value, since in my
> understanding the @type advertises what media type should be negotiated
> with the server, not what should be POSTed.  But perhaps narrowing the
> scope of the link to app:collection would alleviate that?
>

Perhaps.

If there is another way of defining this, in hypertext, that would be grand.
I will update the draft.

--
Erlend

---

From: Darrel Miller <[email-masked]>
Date: Wed, 15 Jan 2014 10:45:04 -0500

Erlend, Peter,

If someone really wants to advertise what content-type can be used in
the POST, the link hints spec [1] has an 'accept-post' property
intended to do this.

Darrel

[1] http://tools.ietf.org/html/draft-nottingham-link-hint-00#section-3.4

On Wed, Jan 15, 2014 at 10:39 AM, Erlend Hamnaberg <[email-masked]> wrote:
> Peter.
>
> On Wed, Jan 15, 2014 at 4:26 PM, Rushforth, Peter
> <[email-masked]> wrote:
>>
>> Erlend,
>>
>>
>>
>> entries.  Ie it specifies what happens generically not based on media type.
>
>
>> understanding the @type advertises what media type should be negotiated with
>> the server, not what should be POSTed.  But perhaps narrowing the scope of
>> the link to app:collection would alleviate that?
>
>
> Perhaps.
>

---

From: Jan Algermissen <[email-masked]>
Date: Wed, 15 Jan 2014 16:46:50 +0100

> My first Internet Draft, please be nice =)

Great!

> Please give feedback.

I am not sure I understand what publishing means to you. Can you explain your context?

In general, I think that you should model 'publishing' as a state change and not as a submission).

Jan

---

From: Erlend Hamnaberg <[email-masked]>
Date: Wed, 15 Jan 2014 16:59:49 +0100

Jan,

On Wed, Jan 15, 2014 at 4:46 PM, Jan Algermissen <[email-masked]
> wrote:

> and not as a submission).
My use case has been a schedule for a conference.

The program is built over time, but once it is done, I want to publish it.

I could, of course, go through each session and publish it directly.
Each publishing step is then a state change for each session.
However, for a user interface can become cumbersome.

However, If I decide to model this as two separate URIs,
I may need a different mechanism.

Not sure I am able to explain this appropriately.

Erlend

---

From: Jan Algermissen <[email-masked]>
Date: Wed, 15 Jan 2014 17:45:03 +0100

> The program is built over time, but once it is done, I want to publish it.

If publishing is done by the same server, I'd change a property of the program to tell the server that it should publish.

When on a nother server, I'd try to POST the program's representation, implicitly creating a new publishing job. That job will have a URI which I would use to observer the state of the job.

Having "publish" point to the publishing system might make sense, in that sense "publish" would identoty a "resource providing publishing services".

I'd ovoid to POST the URI to the publishing service if possible, because it reduces simpicity IMHO, because the publishing system will need to go and GET the resuorec to be published which feels unnatural to me. 

How does that resonate with you?

Jan

---

From: mike amundsen <[email-masked]>
Date: Wed, 15 Jan 2014 13:05:24 -0500

My advice is to *not* attempt to constrain how the client or server behaves
when using the link relation (e.g. "client SHOULD use POST to ....", etc.).

Instead just define the link relation's meaning and let clients and servers
use that shared meaning to do whatever they want with it.

mamund
+1.859.757.1449
skype: mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://linkedin.com/in/mamund

On Wed, Jan 15, 2014 at 11:45 AM, Jan Algermissen <
[email-masked]> wrote:

> If publishing is done by the same server, I'd change a property of the
> program to tell the server that it should publish.
>
> When on a nother server, I'd try to POST the program's representation,
> implicitly creating a new publishing job. That job will have a URI which I
> would use to observer the state of the job.
>
> Having "publish" point to the publishing system might make sense, in that
> sense "publish" would identoty a "resource providing publishing services".
>
> I'd ovoid to POST the URI to the publishing service if possible, because
> it reduces simpicity IMHO, because the publishing system will need to go
> and GET the resuorec to be published which feels unnatural to me.
>

---

From: Darrel Miller <[email-masked]>
Date: Wed, 15 Jan 2014 15:58:52 -0500

Mike,

How do you feel about a link relation that says, if you do POST, it
means this ...

If that concerns you then do you have suggestions on how the these
link relations should work:

rel=payment        https://web-payments.org/specs/source/payment-links/
rel=hub
https://pubsubhubbub.googlecode.com/git/pubsubhubbub-core-0.4.html
rel=oauth2-token http://tools.ietf.org/html/draft-wmills-oauth-lrdd-07#page-8

As far as I understand it, all of these have an associated meaning to
a POST request.  Curiously, that meaning is not described in the rel
relation registration, but in the specification that describes the
protocol that uses the link relation.  This separation concerns me
because we could end up with a situation where different protocols
assign different interaction semantics to the same link relation.

Darrel

On Wed, Jan 15, 2014 at 1:05 PM, mike amundsen <[email-masked]> wrote:
> On Wed, Jan 15, 2014 at 11:45 AM, Jan Algermissen
> <[email-masked]> wrote:
>>
>>
>> it reduces simpicity IMHO, because the publishing system will need to go and
>> GET the resuorec to be published which feels unnatural to me.
>>

---

From: Jan Algermissen <[email-masked]>
Date: Wed, 15 Jan 2014 22:35:24 +0100

> How do you feel about a link relation that says, if you do POST, it

Uuuh - POST means POST ("process this"). A link rel cannot re-specify that.

The rel conveys information about the nature of a target resource. This helps the client to form an expection about the resource and interact with it if it is programmed to do so. Maybe the resource does not even support a POST. 

> rel=payment        https://web-payments.org/specs/source/payment-links/

You are loosing me here ... "payment" already exists in <http://tools.ietf.org/html/rfc5988#section-6.3>. And why is that spec not defining URI template variables and references the URI Template draft? <http://tools.ietf.org/html/rfc6570>

> https://pubsubhubbub.googlecode.com/git/pubsubhubbub-core-0.4.html

The target 'is a hub' - what else do I need to know?

> rel=oauth2-token http://tools.ietf.org/html/draft-wmills-oauth-lrdd-07#page-8

target is a resource where I can obtain an oauth2 token

> a POST request.

Which is simpl not possible - you cannot override HTTP and still be 'within the system'. If you associate meaning with POST, you are defining an application protocol on top of HTTP.

>  Curiously, that meaning is not described in the rel
> protocol that uses the link relation.

Which you can, if you mark it as a 'hint' or 'example' - just do not trick the client into making assumptions that REST deliberately wants the client *not* to make.

The most interesting thing about all this is, IMHO, that you frankly do not need to know, because the method to use is usually sraight forward given the context. I mean, what method would you use for obtaining an oauth2 token? 

>  This separation concerns me

HTTP is for the interaction semantics, link rels can only express the nature of a resource. They cannot constrain the server.

Jan

---

From: mike amundsen <[email-masked]>
Date: Wed, 15 Jan 2014 16:37:06 -0500

I'm not a fan of using a string as a network affordance ;) I know this is
not a universally held conviction. for example, HAL relies on this very
notion quite heavily.

i assert the best way to use link relation values is as identifiers. The
registry let's use describe these values in a general way much the way a
 language dictionary (e.g. English, French, etc.) does. The way in which
the words are used, their intent, implied meaning, etc. are often based on
immediate context ("you owe me a payment" vs. "there is were you go to make
payments") and so forth.

To your last point, I think tying operational semantics to a link relation
is over-constraining and limits it's use over time. Esp. when the
operational semantics are tied to a single protocol or format. I prefer to
keep usage details separate from the registry of unique values.

mamund
+1.859.757.1449
skype: mca.amundsen

On Wed, Jan 15, 2014 at 3:58 PM, Darrel Miller <[email-masked]>wrote:

> rel=oauth2-token
> http://tools.ietf.org/html/draft-wmills-oauth-lrdd-07#page-8
>

---

From: Darrel Miller <[email-masked]>
Date: Wed, 15 Jan 2014 17:18:24 -0500

Jan,

> The rel conveys information about the nature of a target resource. This helps the client to form an expection about the resource and interact with it if it is programmed to do so. Maybe the resourc…

So, you agree that the rel "conveys the nature of a target resource".
And httpbis says

"The POST method requests that the target resource process the
representation enclosed in the request according to the resource's own
specific semantics."

So, if we put those two together then we can determine that the rel
defines the nature of the target resource and the resource defines the
semantics of POST for interactions with that resource.  Hence, I'm
going to conclude that it is not a huge stretch to say that you can
use link relations to define the semantics of a POST.

> You are loosing me here ... "payment" already exists in <http://tools.ietf.org/html/rfc5988#section-6.3>. And why is that spec not defining URI template variables and references the URI Template dr…

Yes rel="payment" does exist already and as far as I know no-one
defined what it really did, or how to use it, so no-one used it.
Someone now is actually trying to define some real semantics for it so
that it can actually be useful.

> The target 'is a hub' - what else do I need to know?

Where in the HTTP spec does it tell me what are the consequences of
doing a POST to link with rel="hub"?  If that information shouldn't be
in the link relation specification, where should it be?

> target is a resource where I can obtain an oauth2 token

How do you get a token?  By doing a GET? a POST?  Where should this be
documented?

> Which is simpl not possible - you cannot override HTTP and still be 'within the system'. If you associate meaning with POST, you are defining an application protocol on top of HTTP.

But we are not redefining the meaning of POST.  Httpbis _explicitly_
says the meaning of POST is defined by the target resource and the rel
tells me that kind of resource that target resource is.

> Which you can, if you mark it as a 'hint' or 'example' - just do not trick the client into making assumptions that REST deliberately wants the client *not* to make.

Let me quote from Roy's famous "REST APIs must be hypertext driven" blog post.

"The only types that are significant to a client are the current
representation’s media type and standardized relation names."

Let me re-phrase that to make my point.  Standard relation names can
be significant to the client.  I.e. In the same way we know from the
content-Type text/html that a tag called <form> can cause the user
agent to generate a POST request with a body
application/x-www-form-urlencoded we can use "Standardized relation
names" to tell the client how to generate POST requests with specific
media types.   Or is your assertion web browsers are making a non
RESTful assumption?

> The most interesting thing about all this is, IMHO, that you frankly do not need to know, because the method to use is usually sraight forward given the context. I mean, what method would you use f…

So, are you asserting is that it is straightforward to know that you
must do a POST with application/x-www-form-urlencoded and a subset of
the following parameters:
grant_type,code,redirect_uri,username,password,scope.  And don't
forget each of those parameters have certain constraints defined by
the OAuth framework.

I apologize if any of this comes across as aggressive, I have tried to
filter out how annoyed I am, but may have failed.  I completely
respect your opinion.  I don't agree with it, but I hope we can work
towards a common ground.

Darrel

---

From: Jan Algermissen <[email-masked]>
Date: Wed, 15 Jan 2014 23:43:01 +0100

On 15.01.2014, at 23:18, Darrel Miller <[email-masked]> wrote:

> semantics of POST for interactions with that resource.

From the POV of the client POST means "process according to what you 'are'". And yes, the link rel leads the client to combine the POST with an expectation about the effect - manifested in the choice of resource (which is lead by the rel).

But I would not got further than that, let alone say "POSTing to a foo means X'.

>  Hence, I'm

How can a link relation spec say anything about what method a resource will support at any given point in time?

But still, what bothers me the most os that you simply do not *need to* say all this.

To me, doing so merely signals RPC-driven thinking (not saying *you* do not 'get it').

> that it can actually be useful.

Hmm, but 'a resource where payment can be made' seems like fine semantics to me. I guess the original idea was somehow connected to "402 Payment Required" - if you find you need to pay for access, rel="payment" is how you find out where.

> in the link relation specification, where should it be?

Isn't the nature of a pubsuhubbub hub just all you need to know?

> How do you get a token?  By doing a GET? a POST?  Where should this be

How would you think you should get a token with an idempotent and safe GET? With a PUT? nah? DELETE?

Hence: POST.

> says the meaning of POST is defined by the target resource

No, it says "process according to .. own semantics". Maybe another, last finding for httpbis?

> and the rel

Hmm, nice point. Will come back on that tomorrow.

> forget each of those parameters have certain constraints defined by

Id id not say I liked OAuth2 or the link rel very much :-)  The stuff you mention above is surely something to be discovered at runtime.
[Set aside maybe the problem that security and discovery don't mix so well since a MITM could trick me in discovering malicious suff :-) I am still personally chewing on discovery and security. Should a 401 response tell a client where an authorization server is???]

> 
> I apologize if any of this comes across as aggressive

Nah - I like sticking to positions rather than giving up too fast. Yields much better analysis.

> , I have tried to
> respect your opinion.  

Dito!

> I don't agree with it, but I hope we can work
> towards a common ground.
> 

I'll chew on that paragraph above. Not having a good answer yet.

Jan

---

From: Darrel Miller <[email-masked]>
Date: Wed, 15 Jan 2014 17:44:46 -0500

Mike,

> not a universally held conviction. for example, HAL relies on this very

Isn't content type a string?  Don't we rely heavily on content type
for conveying semantics?

> language dictionary (e.g. English, French, etc.) does. The way in which the
> words are used, their intent, implied meaning, etc. are often based on

Ideally, all link relations would have no constraints on their
interaction semantics.  However, to say that we should not attach
interaction semantics to a link relation limits, our ability to use
link relations to point to resources that do have limits on their
interaction.  The OAuth2 spec has decided that retrieving a token is
an unsafe operation.  It seems rather ridiculous to have a client that
understands the meaning of the rel="oauth2-token" but has to guess at
what HTTP method to use because we don't want to write that constraint
in the spec.  Sure, we could add link hints to suggest to the client
that probably POST is the right method and add accept-post to tell it
the media type and href vars to tell it the parameters.  Or we could
just document it in the link relation spec and when it has breaking
changes create an oauth3-token.
If we don't convey to the client the details of the OAuth dance via
links and link relations, then how can the client possibly do OAuth
authentication without out of band knowledge.  There is no HTTP header
to say "let's do the OAuth dance".

> keep usage details separate from the registry of unique values.

Yes, tying operational semantics to a link relation is constraining
its usage.  But I think the practical value to be gained by lowering
the idealism bar far outweighs the negatives effects of link relations
with limited applicability.

Don't you remember the time before C+J and HAL and JSON-LD and
JSON-API and Siren when we were being told, there is no need to create
more media types.  I believe the upsurge in the adoption of hypermedia
is due in no small part to the creation of these imperfect hypermedia
types.

Most of the hypermedia I see these days are using extension link
relations. That's because people can't see how they can use standard
link relations in their domains.  We need to loosen the reins and let
some imperfection seep into the link relations.   Having every
developer create their own extension link relations is just as bad as
the "media type explosion" that was feared.

Darrel

---

From: mike amundsen <[email-masked]>
Date: Wed, 15 Jan 2014 18:02:49 -0500

PMFJI...

<snip>
</snip>

The rei is NOT the affordance. It does not tell you how to do anything.

for HTML/HTTP this is one way to know "how":
<form method="get" href="..." class="oauth2-token">...</form>
AND/OR
<form method="post" href="..." class="oauth2-token">...</form>

over CoAP, MQTT, using Cj, Siren, etc. the details will vary but what is
consistent is that you get hits "how" information via the affordance
itself. IMO, do not need to load network semantics into a link rel value.
and, as i mentioned earlier in this thread, i think doing so is a bad idea.

<snip>
</snip>

yes. IF you put those two together. that doesn't mean you MUST. that
doesn't mean putting them together as part of the link rel valu
registration is the best (or only) way to do it. that doesn't even mean it
is a good idea. that just means IF.

<snip>
Hence, I'm going to conclude that it is not a huge stretch to say that you
can use link relations to define the semantics of a POST.
</snip>

not sure what you think you are "stretching" here. the HTTP spec? the
LinkRel registry? logic? credibility? ;D

finally, just because you CAN doesn't mean you SHOULD.

Cheers.

mamund
+1.859.757.1449
skype: mca.amundsen

On Wed, Jan 15, 2014 at 5:18 PM, Darrel Miller <[email-masked]>wrote:

> > The rel conveys information about the nature of a target resource. This
> helps the client to form an expection about the resource and interact with
> it if it is programmed to do so. Maybe the resource does not even support a
> POST.
> >
>
> > You are loosing me here ... "payment" already exists in <
> http://tools.ietf.org/html/rfc5988#section-6.3>. And why is that spec not
> defining URI template variables and references the URI Template draft? <
> http://tools.ietf.org/html/rfc6570>
> >
>
> > Which is simpl not possible - you cannot override HTTP and still be
> 'within the system'. If you associate meaning with POST, you are defining
> an application protocol on top of HTTP.
> >
>
> > Which you can, if you mark it as a 'hint' or 'example' - just do not
> trick the client into making assumptions that REST deliberately wants the
> client *not* to make.
> >
>
> > The most interesting thing about all this is, IMHO, that you frankly do
> not need to know, because the method to use is usually sraight forward
> given the context. I mean, what method would you use for obtaining an
> oauth2 token?
>

---

From: Darrel Miller <[email-masked]>
Date: Wed, 15 Jan 2014 18:37:09 -0500

Mike,

> The rei is NOT the affordance. It does not tell you how to do anything.

Right, the rel is not the affordance it is the "type" of affordance
and in my world, types can define semantics.

> <form method="post" href="..." class="oauth2-token">...</form>

This goes back to our age old debate.  Just because you put a bunch of
parameters in a form doesn't mean the client suddenly knows the
meaning of grant, scope, authorization_code, username.  If you are not
conveying those semantics in the media type (and to my knowledge the
text/html spec hasn't yet absorbed the OAuth spec) then how are you
conveying them?

So here is another question.  Why are you allowed to put interaction
semantics on your <form> tag (e.g. method="get") but it is evil if I
do the same on a <link> tag?  Is this because you feel only media
types are allowed to define interaction details?

> yes. IF you put those two together. that doesn't mean you MUST. that doesn't
> mean putting them together as part of the link rel valu registration is the
> best (or only) way to do it. that doesn't even mean it is a good idea. that
> just means IF.
>
I've never said that you MUST.  I am all for creating link relations
with no interaction semantics where possible.  My problem is that we
are being told that we should not do it and that's where I disagree.
I think that sometimes, it can have value.

> LinkRel registry? logic? credibility? ;D
Our imagination of what is possible without having any significant
negative side effects. :-)

Darrel

---

From: Jan Algermissen <[email-masked]>
Date: Thu, 16 Jan 2014 00:53:07 +0100

On 15.01.2014, at 23:44, Darrel Miller <[email-masked]> wrote:

> There is no HTTP header

WWW-Authenticate: OAuth

Jan

---

From: Jan Algermissen <[email-masked]>
Date: Thu, 16 Jan 2014 01:00:01 +0100

On 15.01.2014, at 23:44, Darrel Miller <[email-masked]> wrote:

> when we were being told, there is no need to create
> more media types.

Well, I didn't :-) Who did?

Sure you need new media types for new 'domains' of applications. (Think 'procurement', for example)

In the  (intra-enterprise) projects I was/am involved in some 5-20 media types was/is a common number.

Jan

---

From: Darrel Miller <[email-masked]>
Date: Wed, 15 Jan 2014 20:10:00 -0500

>> to say "let's do the OAuth dance".

As far as I can tell, OAuth2 isn't registered as an Http authentication scheme.

Darrel

---

From: Jan Algermissen <[email-masked]>
Date: Thu, 16 Jan 2014 08:25:41 +0100

> types are allowed to define interaction details?

Yes, because in the case of a hypermedia response entity the control is embedded in the message (at runtime) - putting that information in the link relation is design time.

We want the client to be prepared for the runtime odds of decentralized systems.

Jan

---

From: mike amundsen <[email-masked]>
Date: Thu, 16 Jan 2014 03:08:42 -0500

<snip>
Isn't content type a string?
</snip>
yes. content type is a string

<snip>
Don't we rely heavily on content type for conveying semantics?
</snip>
no. the content type *string* does not convey (carry) semantics. it is an
identifier of a message design. and  that message design can be used to
craft messages that can carry semantics.

mamund
+1.859.757.1449
skype: mca.amundsen

On Wed, Jan 15, 2014 at 5:44 PM, Darrel Miller <[email-masked]>wrote:

> the

---

From: Erik Wilde <[email-masked]>
Date: Thu, 16 Jan 2014 09:16:35 +0100

hello jan.

> The rel conveys information about the nature of a target resource. This helps the client to form an expection about the resource and interact with it if it is programmed to do so. Maybe the resourc…

a link relation should convey information about how the target is 
related to the source in the given link context, specifically *not* 
information just about the target resource itself. link relations that 
try to define *what* to expect as the target are not all that great; 
instead, they should define *why* a client might want to follow the 
link, and how to do that, given the link context.

cheers,

dret.

-- 
erik wilde | mailto:[email-masked]  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |

---

From: Jan Algermissen <[email-masked]>
Date: Thu, 16 Jan 2014 09:37:31 +0100

On 16.01.2014, at 09:16, Erik Wilde <[email-masked]> wrote:

> a link relation should convey information about how the target is related to the source in the given link context, specifically *not* information just about the target resource itself. link relations that try to define *what* to expect as the target are not all that great; instead, they should define *why* a client might want to follow the link, and how to do that, given the link context.

Hmm, in my world it is exactly the opposite. 

Link rel says "what", client knows "why" (aka "intent") and how is a runtime/introspection time issue.

A link rel spec has no business saying "why" because it cannot know the application a client will be stepping through at any given time.

Jan

---

From: Erik Wilde <[email-masked]>
Date: Thu, 16 Jan 2014 10:13:04 +0100

hello jan.

> Link rel says "what", client knows "why" (aka "intent") and how is a runtime/introspection time issue.

let's say i have an image i want to link to. this may be an image for 
displaying inline, or it may be a page's favicon that goes into browser 
tabs/controls. it may even play both roles. what determines its *role* 
is how it's linked: from an <img> element (equivalent to a "embedded 
image role"), or from <link rel="icon"/>, and if i link it in both ways, 
it plays both roles. *what* it is (PNG, ICO) is not known, and the 
client will have to GET it to see whether it can handle it.

> A link rel spec has no business saying "why" because it cannot know the application a client will be stepping through at any given time.

the *why* allows the client to decide "am i interested in inline images" 
and "am i interested in icon images", and *if* the client is interested 
in them, it will follow the respective links. the containing resource 
types the link and puts it into context, and the client decides whether 
it wants to follow that link, based on its application goal.

it would be bad if the link relation just said "here's some image". and 
notice that neither <img> nor <link rel="icon"/> constrain the target 
resource nor its URI scheme in any way; it's up to the client to decide 
based on the *why* that it wants to engage with the linked resource, and 
then its URI (plus potentially some context of the link, such as a 
<form>'s method attribute) will determine how that interaction looks 
like. that interaction will eventually reveal what you called "the 
nature of the resource", but that's entirely a runtime mechanism and not 
represented by the link relation at all.

cheers,

dret.

---

From: Erlend Hamnaberg <[email-masked]>
Date: Thu, 16 Jan 2014 11:08:14 +0100

Jan,

Trying to bring the disussion back to the topic.

On Wed, Jan 15, 2014 at 5:45 PM, Jan Algermissen <[email-masked]

> program to tell the server that it should publish.

Which property is that?

> sense "publish" would identoty a "resource providing publishing services".

Sure. that is one valid use case.

> and GET the resuorec to be published which feels unnatural to me.

Well, A lot of the services I build are usually proxies to other HTTP based
services. Since this may already be the case, the publishing system can in
its own time determine when it wants to publish each resource.
Either by POSTIng the program as you suggest, or letting the publishing
service get each and figure out how to do that. I see no problem with
either option.

Erlend

---

From: Graham Klyne <[email-masked]>
Date: Thu, 16 Jan 2014 10:35:45 +0000

[Slightly off-topic...]

Mike,

Accepting that the operational details be separate from the link relation 
semantics...

In your (REST-informed?) view, where the link relation occurs within some 
retrieved representation, would be be reasonable for the representation to 
*also* indicate the operations that might be applicable?  (Somewhat like HTML 
<form> @method, maybe.)

For example, to abuse an example from Darrel's draft [1]:

        <link rel="self" type="application/atom+xml"
            href="http://example.org/feed"/>
        <link rel="publish"
          href="http://example.org/publish"/
          method="POST" post_types="text/uri-list" />

("method" and "post-types" here are pure invention for the purpose of discussion.)

So in this context, a client can move straight to the publication step, which I 
think is Darrel's goal with the operational discussion in the link relation.  In 
a different context, a client might have to perform a GET (or equivalent) to the 
linked resource to discover its affordances.

#g
--

[1] http://www.ietf.org/id/draft-hamnaberg-publish-link-relation-00.txt

---

From: Jan Algermissen <[email-masked]>
Date: Thu, 16 Jan 2014 13:29:31 +0100

On 16.01.2014, at 11:35, Graham Klyne <[email-masked]> wrote:

> [Slightly off-topic...]
> 
> Mike,
> 
> Accepting that the operational details be separate from the link relation semantics...
> 
> In your (REST-informed?) view, where the link relation occurs within some retrieved representation, would be be reasonable for the representation to *also* indicate the operations that might be applicable?  (Somewhat like HTML <form> @method, maybe.)
> 
> So in this context, a client can move straight to the publication step, which I think is Darrel's goal with the operational discussion in the link relation.  In a different context, a client might have to perform a GET (or equivalent) to the linked resource to discover its affordances.

The problem is that you are making the specification of the link rel overly complex by extending already established linking specs.

If you want HTTP-header inline forms with similar semantics of HTML forms, I'd roll an I-D - but I would not try to bake it into something else using extensions.

As to why the operational semantics need not go into the rel spec, I just remembered this:

http://www.imc.org/atom-protocol/mail-archive/msg03925.html

in which Roy is touching the issue that you ust do not need to know operational semantics - it is a configuration-time issue (or call it introspection time).

Looking for tighter coupling by baking operational constraints into design time information is just trying to 'fix' the runtime uncertainty that REST deliberately makes explicit (REST aims to do away with the constraints because they are too constly to hold up in a decentralized environment).

Just assume the POST based on context and prepare the client that it might fail.

jan