"home" link relation

[dret]

would it make sense to add a "home" link relation to the home document draft? if not, should the draft maybe suggest the use of an existing one to use when linking to a home document? "start" maybe isn't terrible when just looking at the name, but then again it seems to be more "first" than "home" when looking at the definition: "Refers to the first document in a collection of documents. This link type tells search engines which document is considered by the author to be the starting point of the collection." https://www.w3.org/TR/1999/REC-html401-19991224/types.html#type-links

[dret]

any thoughts on this? seems like having a standardized way to link to "home documents" (whatever media type they may use) could be a useful thing to add. if you agree, i can add a section.

[dret]

if "home" is added, it might be interesting to see how it compares to the relation types proposed by https://tools.ietf.org/html/draft-wilde-service-link-rel

[ethanresnick]

The contents relation originally from html might also be able to do this. I'm curious what others think about that though!

[dret]

https://www.w3.org/TR/1999/REC-html401-19991224/types.html#type-links says that contents 'Refers to a document serving as a table of contents. Some user agents also support the synonym ToC (from "Table of Contents").'
to me, that's a bit different from "home" itself (for example, at a "home" resource you might even find a link to a "contents" resource), but i am curious to hear more opinions as well!

[dret]

thinking about the relation of the proposed home to https://tools.ietf.org/html/draft-wilde-service-link-rel a bit more, it seems to me it's fairly simple: home links to the actual home resource of the service from where the assumption is application flows start initially; the relations proposed by https://tools.ietf.org/html/draft-wilde-service-link-rel link to where these flows are documented, either in human- or in machine-readable ways. typically, the resource provided at home might have those links to service documentation and description.

[dret]

@mnot, any thoughts on this one? if you're ok, i'd be happy to contribute a PR, containing a bit of explanatory text, and the appropriate IANA registration template.

[asbjornu]

I agree that a home relation would be useful. It conveys something different from contents, up and start. It would be useful if the text for the registration of the home relation explained this difference explicitly, I think.

[dret]

On 2016-06-16 04:18, Asbjørn Ulsberg wrote:

I agree that a |home| relation would be useful. It conveys something
different from |contents|, |up| and |start|. It would be useful if the
text for the registration of the |home| relation explained this
difference explicitly, I think.

link relations are fuzzy by nature so it will be hard to differentiate
these things in a definitive way. but i would certainly try and as
usual, feedback will be very much appreciated.

[dret]

for now, dret/I-D@3002e1f (the "XML syntax for home documents" draft) is where i have added the "home" link relation type. at least it's somewhere, and i'd be fine to migrate it to the core spec when/if the time seems right.

[dret]

https://tools.ietf.org/html/draft-wilde-home-xml-04#section-4.3.1

[mnot]

So, what are the actual use cases here? Do you envision it occurring in representations sent to API clients (non-browser), or to browsers, or...?

[dret]

On 2016-11-23 12:21, Mark Nottingham wrote: So, what are the actual use cases here? Do you envision it occurring in representations sent to API clients (non-browser), or to browsers, or...?

more to non-browsers than to browsers. API people i am talking to seem to like the idea that there's a simple way to get from any resource to a home document (and from there potentially to additional resources such as service documentation or description). there's not a lot of harm in defining such a link relations, i'd say.

[mnot]

I think that makes sense.

[dret]

On 2016-11-26 23:20, Mark Nottingham wrote: I think that makes sense.

i'll try to come up with a PR, then. the contribution process is to update draft.md which is your "latest draft source", right?

[algermissen]

As a note to this thread: I am using a Well-Known URI for the purpose of finding the home document of a server (/.well-known/home). It has less capabilities compared to a link rel, but has served me well over the years.

[dret]

On 2017-03-01 09:09, Jan Algermissen wrote: As a note to this thread: I am using a Well-Known URI for the purpose of finding the home document of a server (/.well-known/home). It has less capabilities compared to a link rel, but has served me well over the years.

i am sure you are aware that this is not a registered well-known URI. https://www.ietf.org/assignments/well-known-uris/well-known-uris.xml however, maybe it would be a good idea to register "home" as a well-known URI? i'll open a new issue for that.

[dret]

PR: #214

[asbjornu]

however, maybe it would be a good idea to register "home" as a well-known URI? i'll open a new issue for that.

@dret: That sounds like a good idea. Would you say it's okay for that well-known URI to do an HTTP 301 to i.e. / for applications where that make sense?

[dret]

On 2017-03-01 16:46, Asbjørn Ulsberg wrote: however, maybe it would be a good idea to register "home" as a well-known URI? i'll open a new issue for that. @dret <https://github.com/dret>: That sounds like a good idea. Would you say it's okay for that |well-known| URI to do an HTTP |301| to i.e. |/| for applications where that make sense?

let's head over to #212 for this topic

[mnot]

#214 merged; thanks!