Subject: Re: [link-relations] Review of draft-ioseb-dzmanashvili-link-relation-00

From: Ioseb Dzmanashvili <[email-masked]>
Date: Tue, 8 May 2012 12:21:39 +0400

Hello Jan,

Thanks for the questions!

> You mention two link relations, but so far I can only see one ('form').
Which is the other one you are going to define?

I'm not sure regarding this, i never mentioned another link relation type.
I only created draft for form?

> What is the exact purpose of the 'form' link relation? AFAIU the client
would do a GET on the link target and interpret the response body as a form
for adding entries.

Exactly.

> Can you explain a bit, what the use cases are you have in mind for this?
Does it make sense to define such a relation in a general manner? Why?

As i see it i believe it makes total sense. I use it for several purposes
and i'm finding it really useful in lot of cases:

- When *read* representation of the resource is different and doesn't
contain enough informations about resource properties(which property is
editable, which is not, which is required which is optional etc..)
- When using different media types, for example if resource is represented
in media format which lacks write semantics i use this link relation with
type attribute, dereferencing of target URI returns resource representation
which describes writing/editing requirements.
- When have a long list of editable items and it's not reasonable to
include write forms alongside with items
- When have an API which most of the time is used for reading purposes but
also offer write capabilities.
- When building self describing APIs which may guide clients through write
process without need in any additional information.

(for additional information here is the thread related to this relation:
http://www.ietf.org/mail-archive/web/link-relations/current/msg00313.html)

> Do you envision the specification of certain media types for the forms to
be returned?

Any media type which offers "form" semantics can be used. There was no
specific media type on my mind when i was thinking about it.

What i can say from my practice i was always using XHTML
forms(application/xhtml+xml) and some custom JSON formats for such
purposes.  Recently i heavily started to use:

- Collection+JSON: http://amundsen.com/media-types/collection/format/
 (application/vnd.collenction+json)

and it's extension(which i authored)

- Collection.next+JSON:
http://code.ge/media-types/collection-next-json/(application/vnd.collection.next+json)

Both are registered media types and both offer *forms*.

> Have you considered using media type semantics instead of link relations?
It would in my opinion be better to define a form media type and make the
distinction between add and edit part of the type, not of the context in
which a link is found.

As i noted above i use media types which already offer *form* capabilities,
additionally Collection.next+JSON offers *method* attribute which can be
successfully used for indicating this distinction(IMHO of course). I do not
see problems with dedicated media type, though i do not think it's an ideal
solution. As i understand this will create dependency on media type.

> Have you looked at Mark Baker's RDF Forms[2]? Maybe you can build on that
approach for your purpose?

I'm aware of RDF Forms, but i do not see it as a solution for everything
and especially for simple cases where JSON interaction works really well.

Below is the simple example use case:

==Request==

| GET /users HTTP/1.1
| Host: service.org
| Accept: application/vnd.collection.next+json

==Response==

| HTTP/1.1 200 Ok
| Content-Type: application/vnd.collection.next+json
| Content-Length: ...

| {"collection": {
|   "version": "1.0",
|   "href": "http://service.org/users",
|   "items": [
|     {
|       "href" : "http://service.org/users/john-doe",
|       "data" : [
|         {"name": "name",    "value": "John Doe",     "prompt": "Full
name"},
|         {"name": "email",   "value": "[email-masked]", "prompt": "Email"},
|         {"name": "website", "value": "",             "Prompt": "Website"}
|       ],
|       "links" : [
|         {
|           "href":   "http://service.org/users/john-doe/form",
|           "rel":    "form",
|           "type":   "application/vnd.collection.next+json"
|           "prompt": "Edit user"
|         }
|       ]
|     },
|     {...},
|     {...},
|     {...}
|   ]
| }}

==Request: dereference the form resource==

| GET /users/john-doe/form HTTP/1.1
| Host: service.org
| Accept: application/vnd.collection.next+json

==Response==

| HTTP/1.1 200 Ok
| Content-Type: application/vnd.collection.next+json
| Content-Length: ...

| {"collection": {
|   "version": "1.0",
|
|   "template": {
|     "method": {
|       "options": [
|         {"value": "PUT",   "prompt": "Replace Entry"},
|         {"value": "PATCH", "prompt": "Modify Entry"}
|       ]
|     },
|     "data": [
|       {"name": "first_name", "value": "John", "prompt": "First name",
"required": true},
|       {"name": "last_name",  "value": "Doe",  "prompt": "Last name",
 "required": true},
|       {"name": "website",    "value": "",     "prompt": "Website",
 "type":     "url"}
|     ]
|  }
| }}

==Request: submit the modified form element==

| PATCH /users/john-doe HTTP/1.1
| Host: service.org
| Content-Type: application/vnd.collection.next+json
| Content-Length: ...

| {"template": {
|   "data": [
|     {"name": "website", "value": "http://john.doe.com"}
|   ]
| }}

Best regards,
Ioseb

> ---------- Forwarded message ----------
> From: Jan Algermissen <[email-masked]>
> To: [email-masked]
> Cc:
> Date: Mon, 7 May 2012 20:26:39 +0200
> Subject: [link-relations] Review of
> draft-ioseb-dzmanashvili-link-relation-00
> Hi Ioseb,
>
> I have just looked at your draft[1] and have a couple of questions:
>
> You mention two link relations, but so far I can only see one ('form').
> Which is the other one you are going to define?
>
> What is the exact purpose of the 'form' link relation? AFAIU the client
> would do a GET on the link target and interpret the response body as a form
> for adding entries.
>
> Can you explain a bit, what the use cases are you have in mind for this?
> Does it make sense to define such a relation in a general manner? Why? Do
> you envision the specification of certain media types for the forms to be
> returned?
>
> Then you mention the use of 'form' to edit single member entries. I find
> this to be problematic because the meaning of the returned form (that is,
> the effect of submitting the form, depends on the context in which the form
> has been found. In one case it will be 'add a member' in the other it will
> be 'update a resource'.
>
> Have you considered using media type semantics instead of link relations?
> It would in my opinion be better to define a form media type and make the
> distinction between add and edit part of the type, not of the context in
> which a link is found.
>
> .....
>
> Have you looked at Mark Baker's RDF Forms[2]? Maybe you can build on that
> approach for your purpose?
>
> Jan
>
>
> [1] http://www.ietf.org/id/draft-ioseb-dzmanashvili-link-relation-00.txt
> [2] http://www.markbaker.ca/2003/05/RDF-Forms/
>
> _______________________________________________
> link-relations mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/link-relations
>
>
-- 
Ioseb Dzmanashvili
Lead Architect
Picktek LLC
24b Khazbegi ave.
Tbilisi, 0177, Georgia
T (+995 32) 39.58.56, F (+1 202) 315.3934
picktek.com
code.ge
github.com/ioseb
twitter.com/iosebi

---

From: Jan Algermissen <[email-masked]>
Date: Thu, 10 May 2012 23:13:39 +0200

Ioseb,

On May 8, 2012, at 10:21 AM, Ioseb Dzmanashvili wrote:

> > You mention two link relations, but so far I can only see one ('form'). Which is the other one you are going to define?
> 
> I'm not sure regarding this, i never mentioned another link relation type. I only created draft for form? 

Your draft says: "This specification defines a pair of reciprocal link relation types" - I took 'pair' to mean 'two' , no? 

> |         {"name": "name",    "value": "John Doe",     "prompt": "Full name"},

How do I know the meaning of 'form' here? Will this add a new entry?

Jan

> |       {"name": "first_name", "value": "John", "prompt": "First name", "required": true},
> |       {"name": "last_name",  "value": "Doe",  "prompt": "Last name",  "required": true},
> |       {"name": "website",    "value": "",     "prompt": "Website",    "type":     "url"}
> |     ]
> |  }
> | }}
> 
> Subject: [link-relations] Review of draft-ioseb-dzmanashvili-link-relation-00
> Hi Ioseb,
> 
> You mention two link relations, but so far I can only see one ('form'). Which is the other one you are going to define?
> 
> What is the exact purpose of the 'form' link relation? AFAIU the client would do a GET on the link target and interpret the response body as a form for adding entries.
> 
> Can you explain a bit, what the use cases are you have in mind for this? Does it make sense to define such a relation in a general manner? Why? Do you envision the specification of certain media types for the forms to be returned?
> 
> Then you mention the use of 'form' to edit single member entries. I find this to be problematic because the meaning of the returned form (that is, the effect of submitting the form, depends on the context in which the form has been found. In one case it will be 'add a member' in the other it will be 'update a resource'.
> 
> Have you considered using media type semantics instead of link relations? It would in my opinion be better to define a form media type and make the distinction between add and edit part of the type, not of the context in which a link is found.
> 
> .....
> 
> Have you looked at Mark Baker's RDF Forms[2]? Maybe you can build on that approach for your purpose?
> 
> Jan
> 
>

---

From: Ioseb Dzmanashvili <[email-masked]>
Date: Fri, 11 May 2012 10:43:37 +0400

Hi Jan,

> Your draft says: "This specification defines a pair of reciprocal link relation types" - I took 'pair' to mean 'two' , no?

Thanks for pointing this, i didn't notice it. You are absolutely correct it's a my mistake.  I updated the draft with following text:

RFC 5988 [RFC5988] defined the way of indicating resources on the Web. This specification defines a link relation type which may be used to express the relationships between a collection and an input form for adding additional member items to the context collection, or between an item and a pre-populated input form for modifying the context item.

http://www.ietf.org/id/draft-ioseb-dzmanashvili-link-relation-01.txt
 
> > | Host: service.org (http://service.org)
> > | {"name": "email", "value": "[email-masked] (mailto:[email-masked])", "prompt": "Email"},
Well, in this case link is included within an item which is a member of a collection as defined per spec. It clearly should mean *modify* not *add*.

Ioseb

> > | Host: service.org (http://service.org)
> > | Host: service.org (http://service.org)
> > From: Jan Algermissen <[email-masked] (mailto:[email-masked])>
> > To: [email-masked] (mailto:[email-masked])
> > Cc: 
> > [email-masked] (mailto:[email-masked])
> > picktek.com (http://picktek.com)
> > code.ge
> > github.com/ioseb (http://github.com/ioseb)
> > twitter.com/iosebi (http://twitter.com/iosebi)
> > 
> 
> 
>

---

From: Ioseb Dzmanashvili <[email-masked]>
Date: Fri, 11 May 2012 12:57:26 +0400

Jan,

I was thinking about your question regarding understanding of meaning of *form*. I'm not 100% sure, though as far as it's possible to specify multiple link types as a value of the *rel* attribute and there are already registered link relations of *collection* and *item* types as per RFC6573 <http://tools.ietf.org/html/rfc6573>, in order to signify meaning of the *form* link type in resource representations it's possible to define links this way:

== For collection ==
| {
|   "links": [
|     {
|       "href": "http://...",
|       "rel": "collection form",
|       "prompt": "Add new entry..."
|     }
|   ]
| }

== For item ==
| {
|   "links": [
|     {
|       "href": "http://...",
|       "rel": "item form",
|       "prompt": "Edit entry..."
|     }
|   ]
| }

Again, i'm not 100% sure, though i believe it's much clear.

P.S.
Most recent version of draft: http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-02

Best regards,
Ioseb

---

From: Jan Algermissen <[email-masked]>
Date: Fri, 11 May 2012 11:06:32 +0200

On May 11, 2012, at 10:57 AM, Ioseb Dzmanashvili wrote:

> Jan,
> 
> I was thinking about your question regarding understanding of meaning of *form*.

What is troubling me is that the meaning of 'form' depends on the meaning of 'collection' vs 'item'. Hence, Effectively the 'form' spec depends on some other spec that defines what 'collection' and 'item' means. 

This in turn means that a client must understand the other specs (the media type of the context of the 'form' link) to understand which meaning of form is in effect.

I'd rather define two new relations, or, make the form apply to both cases equally and let the client figure out the submission target URI. (Who says the form must contain the target?)

That way 'form' would mean: 'here is a form that you can use to construct entry-submissions'. If you intend to edit an entry, use the form and if you intend to create a new entry use that form too.

Send the form to the appropriate target URI.

E.g.

GET /feed

200 Ok,
Link: </feed/entry-form>; rel=form

<feed>
  <entry>
    <link rel="edit" href="/entries/665"/>
  </entry>
  ....
</feed>

Then

GET /feed/entry-form

200 Ok
Content-Type: application/myform

<form>
</form>

Then use the form to construct the payload for the request

- to create a new entry and POST to /collection
or
- to update an entry and PUT to e.g. /entries/665

makes sense?

Jan

> I'm not 100% sure, though as far as it's possible to specify multiple link types as a value of the *rel* attribute and there are already registered link relations of *collection* and *item* types as per RFC6573 <http://tools.ietf.org/html/rfc6573>, in order to signify meaning of the *form* link type in resource representations it's possible to define links this way:
> 
> == For collection ==
> | {
> |   "links": [
> |     {
> |       "href": "http://...",

---

From: Ioseb Dzmanashvili <[email-masked]>
Date: Fri, 11 May 2012 15:51:48 +0400

Thanks Jan!

> What is troubling me is that the meaning of 'form' depends on the meaning of 'collection' vs 'item'. Hence, Effectively the 'form' spec depends on some other spec 
> that defines what 'collection' and 'item' means.

That's why I was not 100% sure when suggested this approach. I absolutely agree with you.

>I'd rather define two new relations, or, make the form apply to both cases equally and let the client figure out the submission target URI. (Who says the form must contain the target?)

If i understand you correctly, this means that there can be only one form for creating or updating entry. If this is the case, how it solves the problem when create and update forms differ from each other? or when intent is to offer already pre-populated form? In this case defining these relations separately will work better i believe. 

I think re-defining the *form* as a generic type with meaning like "here is the form and use it for to construct submissions" and additional type *update-form* with meaning like "here is the entry/record/item and the related *pre-populated* form, use it to modify the entry and construct submission". In other words what i'm trying to achieve is to have the ability to manage both - create and update forms separately and coordinate client interactions.

== Retrieve feed ==
| GET /feed HTTP/1.1
| Host: service.com

== Response ==
| HTTP/1.1 200 OK
| Link: </feed/form>; rel=form; title=Create new entry

| <feed>
|   <entry>
|     ...
|     <link rel="self" href="/entries/665" />
|     <link rel="update-form" href="/entries/665/form" title="Update entry" />
|   </entry>
| </feed>

Does it make sense?

Best regards,
Ioseb

---

From: Jan Algermissen <[email-masked]>
Date: Fri, 11 May 2012 13:58:02 +0200

On May 11, 2012, at 1:51 PM, Ioseb Dzmanashvili wrote:

> 
> If i understand you correctly, this means that there can be only one form for creating or updating entry. If this is the case, how it solves the problem when create and update forms differ from each other? or when intent is to offer already pre-populated form?

Ah, sure - you are right. Missed that.

> In this case defining these relations separately will work better i believe.

Yes - that would also not be a harm, IMHO.

> |     <link rel="update-form" href="/entries/665/form" title="Update entry" />

Yes, feels better. I'll let it circle through my head whether there is something else to it.

BTW, what would the reaction be if I POST to create without form and the server does not 'allow' that?

Should this maybe be mentioned in the spec as a hint? Any better/additional idea?

POST /feed
Content-Type: application/order

<order/>

415 Unsupported Media Type
Link: </feed/form>; rel=form; title=Create new entry
Content-Type: text/html

<html>
.... Use <a href="/feed/form" title="Entry Creation Form">this form</a> to create a new entry.
</html>

Jan

---

From: Jan Algermissen <[email-masked]>
Date: Fri, 11 May 2012 14:11:50 +0200

>> |     <link rel="update-form" href="/entries/665/form" title="Update entry" />

Interesting thing is that a human targeted user agent could treat the form-links like HTML <img> links and download the forms right away, embedding them in the UI directly (maybe hidden of course). A bit like a 'typed' AJAX request.

Cool stuff, actually.

Jan

---

From: Ioseb Dzmanashvili <[email-masked]>
Date: Fri, 11 May 2012 16:30:00 +0400

Jan, 

> Should this maybe be mentioned in the spec as a hint? Any better/additional idea?

For me this sounds fantastic, i believe it's absolutely makes sense to include this in spec(i can't think about anything better for this). Thanks for this!

P.S.
I'll start to work on redefining the spec and will share descriptions here before updating the document. Thanks for great discussion!

Ioseb 

On Friday, May 11, 2012 at 3:58 PM, Jan Algermissen wrote:

> > | Host: service.com (http://service.com)
> > 
> > == Response ==
> > | HTTP/1.1 200 OK

---

From: Ioseb Dzmanashvili <[email-masked]>
Date: Fri, 11 May 2012 16:31:55 +0400

> Interesting thing is that a human targeted user agent could treat the form-links like HTML <img> links and download the forms right away, embedding them in the UI > 
> directly (maybe hidden of course). A bit like a 'typed' AJAX request.
> Cool stuff, actually.

I'm glad you like it!!!

ioseb

---

From: Ioseb Dzmanashvili <[email-masked]>
Date: Sat, 12 May 2012 02:13:46 +0400

Hello Jan,

I update the spec http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-03 it included comprehensive information now(including you suggestions + acknowledgements). It's much better now i think.

Best regards,
Ioseb

---

From: Ioseb Dzmanashvili <[email-masked]>
Date: Sat, 12 May 2012 02:17:10 +0400

Hello Jan,

I updated the spec http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-03 it includes comprehensive information now(including you suggestions + acknowledgements). It's much better now i think.

Best regards,
Ioseb

---

From: Jan Algermissen <[email-masked]>
Date: Sat, 12 May 2012 00:03:55 +0200

> I update the spec http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-03 it included comprehensive information now(including you suggestions + acknowledgements). It's much better now…

Thanks, I think so, too.

There are a few wording issues (though I am far from being an expert on this :-) which I will try comment on the next days.

Also, consider changing form to create-form to make the two more aligned. (No idea, BTW, whether - is allowed in the shortname)

Think about dropping the passages that talk about where the link is found (e.g. in a collection or item) because that mandates that you explain what a collection or item is. It is not necessary anymore anyhow because the link rels are now context independent.

I'd rather say: 

create-form points to a resource where you can find a form to be used to append an item to the link context ('append' is fine in this case IMHO because HTTP implicitly defines what that means in the POST section of the spec.)

update-from points to a resource where you can find a form to update the link context.

Think about it.

Good work!

Jan

---

From: Ioseb Dzmanashvili <[email-masked]>
Date: Sat, 12 May 2012 02:25:44 +0400

Thanks for quick response and suggestions! 

I'll modify link relation name and texts over weekend for sure.

Ioseb

---

From: Ioseb Dzmanashvili <[email-masked]>
Date: Sat, 12 May 2012 02:50:50 +0400

Changed link relation name and some wording: http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-04

Thanks again! 

Best regards,
Ioseb

---

From: Ioseb Dzmanashvili <[email-masked]>
Date: Mon, 14 May 2012 11:36:23 +0400

Hello,

I've updated draft for "create-form" and "update-form" link relations. Fixed several minor issues and added table of contents. 

Reviews are highly appreciated. Thanks in advance!

Best regards,
Ioseb

---

From: Ioseb Dzmanashvili <[email-masked]>
Date: Mon, 14 May 2012 11:44:03 +0400

Updated link: http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-05

---

From: Jan Algermissen <[email-masked]>
Date: Tue, 15 May 2012 11:31:16 +0200

Review of http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-05

Abstract

"between any kind of entry and a pre-populated input form for modifying the associated entry"
s/pre-populated input//

Introduction

"between any kind of entry and a pre-populated input form for modifying the associated entry"
s/pre-populated input//

Consider dropping the second paragraph or rewrite so that it does not imply that sometimes link relations would be tied to a media type (which they must never be).

3.1.1

Do not constrain the method use. It is a runtime choice the client makes. If the form media type includes method information the client will (usually) be programmed to use that , otherwise, your draft must not constrain method use.

As a client I can try create resources using PUT as often as I desire - the server will tell me at runtime whether it worked.

If you feel you must say something here, make it a hint along the lines of "If the client has no particular information about what method to use a POST would be the best guess"

Not sure about the SHOULD in the 415 example - using SHOULD here makes your draft depend normatively on the 415 spec and the fact that 415 is the code to use for the described case is inherent in the nature of 415. No need to repeat that here. Maybe emphasize that it is an example.

3.1.2
see 3.1.1 comments :-)

4.2. consider s/update-form/edit-form/ ?

I think 4.1 and 4.2 need slight rephrasing, but I am not an experience I-D writer. If I think of something I'll let you know.

Jan

---

From: Ioseb Dzmanashvili <[email-masked]>
Date: Tue, 15 May 2012 14:58:50 +0400

Hi Jan, 

Thanks for review!

Here are changes i made(i didn't submit draft yet):

> "between any kind of entry and a pre-populated input form for modifying the associated entry" s/pre-populated input//

Changed this: "This specification defines link relation types which may be used
   to express the relationships between a resource and an input form for
   constructing entry submissions, or between any kind of entry and a
   pre-populated input form for modifying the associated entry."
   
to this: "This specification defines link relation types which may be used
      to express the relationships between a resource and an input form for
      constructing data submissions."

> Not sure about the SHOULD in the 415 example - using SHOULD here makes your draft depend normatively on the 415 spec and the fact that 415 is the code to use for the described case is inherent in t…

Chanted this: "If the media type, used for constructing submission form, supports
   target URI information provisioning, explicitly specified target URI
   MUST be used by clients for submitting the populated form.  Context
   URI MUST be used otherwise."
   
to this: "Target URI specified in the form representation MUST be used for
      submit requests.  Context URI MUST be used otherwise."

--------

Changed this: "If the media type, used for constructing submission form, supports
   method information provisioning, explicitly specified request method
   MUST be used by clients for submitting the populated form.  HTTP's
   PUT method MUST be used otherwise."
   
to this: "Request method specified in the form representation MUST be used for
      submit requests.  HTTP's POST method MAY be used otherwise."

---------

Changed this: "If the media type, used for constructing submission form, supports
   content encoding information provisioning, form data MUST be encoded
   according to the explicitly specified encoding type before
   submission.  The media type used for constructing form MUST be used
   otherwise."
   
to this: "Content type specified in the form representation MUST be used for
      submit requests.  The content type of the form representation MUST be
      used otherwise."

----------------

in 3.2. changed this: "When included in a resource which represents particular entry, the
         "update-form" link relation identifies a target resource that
         represents a pre-populated form for editing associated entry."

to this: "When included in a resource, the "edit-form" link relation
     identifies a target resource that represents the form for editing associated resource"

> 4.2. consider s/update-form/edit-form/ ?

Done

> I think 4.1 and 4.2 need slight rephrasing, but I am not an experience I-D writer. If I think of something I'll let you know.

in 4.1 changed this: "The target IRI points to a resource that is a representation of a
      valid submission form for the data described by the form resource"
      
to this: "The target IRI points to a resource that is a representation of a
            valid submission form."

----------

in 4.2 changed this: "The target IRI points to a resource that is a representation of a
      valid pre-populated submission form for editing the data
      represented by the associated entry."
      
to this: "The target IRI points to a resource that is a representation of a
            valid submission form for editing associated resource."

Best regards,
Ioseb

---

From: Jan Algermissen <[email-masked]>
Date: Tue, 15 May 2012 15:43:35 +0200

>       constructing data submissions."

Sounds good.

>       submit requests.  Context URI MUST be used otherwise."

Agreed.

>       submit requests.  HTTP's POST method MAY be used otherwise."

Ok.

>       submit requests.  The content type of the form representation MUST be

This sounds wrong to me. I get your point I think, but the question of what to send if the form does not tell you seems orthogonal to your draft to me.

Getting a second opinion here might be a good idea.

'representation' here sounds (to me) misleading. What about 'points to a resource where a creation form can be obtained'?
(Though I dislike 'creation form' here)

Anyhow - maybe yours is just good enough...

Thanks for the quick responses.

Jan

---

From: Ioseb Dzmanashvili <[email-masked]>
Date: Tue, 15 May 2012 18:33:16 +0400

Hi Jan, 

Thank you very much!

> Getting a second opinion here might be a good idea.

Maybe this? 

"A content type specified in the form representation MUST be used for submitting requests, or otherwise, a content type defined in the media type specification of a form MUST be used"

For example form HTML forms, for data submission default content type is "application/x-www-form-urlencoded" but in some cases "multipart/form-data" can be indicated explicitly. Both cases are defined by media type spec itself. 

>> "The target IRI points to a resource that is a representation of a
>> valid submission form."

> (Though I dislike 'creation form' here)

What about this? 
"The target IRI points to a resource where a submission form can be obtained"

What do you think? 

ioseb

---

From: Ioseb Dzmanashvili <[email-masked]>
Date: Wed, 16 May 2012 13:30:01 +0400

Hi Jan, 

I updated the draft: http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-06

All discussed changes are there. Additionally, as you suggested i moved error handling example to separate sub section, removed "SHOULD" and changed wording from "service SHOULD respond" to "service may  respond";

Best regards,
Ioseb

---

From: Jan Algermissen <[email-masked]>
Date: Wed, 16 May 2012 08:55:04 +0200

> "A content type specified in the form representation MUST be used for submitting requests, or otherwise, a content type defined in the media type specification of a form MUST be used"

Why do you need to say this at all? IWO, what is missing if you drop it?

> For example form HTML forms, for data submission default content type is "application/x-www-form-urlencoded" but in some cases "multipart/form-data" can be indicated explicitly. Both cases are defi…

Right - and they are defined *there* - why do you want to say in your draft that one must obey other drafts?
> "The target IRI points to a resource where a submission form can be obtained"

Yes, I guess that works.

(Admittedly, I am still unsure how appropriate this language-tweaking is for I-Ds. I guess one could go on forever fiddling with the words. I lack a quality indicator, telling me that 'we are done' :-)

@Mark, Julian ... if you read this, drop me note what balance makes sense.

Jan

---

From: Ioseb Dzmanashvili <[email-masked]>
Date: Wed, 16 May 2012 14:41:24 +0400

Thank you very much Jan!

> Right - and they are defined *there* - why do you want to say in your draft that one must obey other drafts?

I'd be rather happy do drop this at all. I'm just not sure what exactly needs to be included in the draft and what is not(obviously this is due to my lack of experience in writing drafts) ;) 

> @Mark, Julian ... if you read this, drop me note what balance makes sense.

That would be great!

Best regards,
Ioseb