Re: RFC 8288 on Web Linking

Ivan,

As Hadrien said, this is a relatively minor revision. At least as far as the tech side of things is concerned.

Extension link relations (i.e. type values that are URLs) are a long-standing feature of link relations. They aren’t ‘private’ link relations; it's just a defined process for third parties to create or use link relations that are unambiguous and won’t conflict with registered link relations. E.g. the EPUB Structural Semantics vocabulary could be used as extension link relations (each term has both an unambiguous URL and clearly defined semantics) but isn’t private in any meaningful way.

Actual ‘private' link relations are a different thing, they are unregistered non-URL types whose meaning is specific to the local document (noted in https://tools.ietf.org/html/rfc8288#appendix-A.1).

The changes between the specs are outlined in Appendix C: https://tools.ietf.org/html/rfc8288#appendix-C

I’ve been lurking on the discussions around this spec for a while and as I understand it, a lot of the work has been about clarifying how link relations work across different segments of the web ecosystem and updated to reflect how many of the relevant specifications have changed over the past few years: 

* They clarified that assigning URIs to registered link relations is serialisation-specific. (Funnily enough, unregistered URI-based link relations are more easily compatible with formats like JSON-LD for this reason.)

* The explanation of the relationship this spec and HTML was updated to reflect the changes from HTML4 to HTML5.

* They also added a bunch of clarifications on how the link header should be parsed.

Finally, IIRC, the registration process was reviewed and some of its goals and procedures changed. Specifically, registration should now be a little bit more ad hoc and simpler as it does away with application data fields and a few procedural complexities. The goal of the registry is now to reflect common use of links on the Internet and is specifically intended to be strongly biased towards including link relations. Which is a fairly substantial policy change, AFAICT, as before it was only really concerned with registering the link relations that had been defined in specifications by standards organisations. 

That aligns the registry to be more in line with the needs of the HTML5, which currently refers to the microformats wiki page for link relations. The IETF's plan, according to this update, is for the IANA registry to at least mirror the contents of the microformats wiki page and they are hoping it can serve well enough to replace it in the long run.

- best
- Baldur Bjarnason
  baldur@rebus.foundation



> On 27 Oct 2017, at 11:53, Ivan Herman <ivan@w3.org> wrote:
> 
> Heather,
> 
> is there a pointer to the changes? I mean I presume such a spec already existed before, and this is just a new version. At first glance, I have not seen anything in the document that stroke me as absolutely new
> 
> (Maybe one: that it is possible to use a URI for a 'private' link relation type, ie, not necessarily use a registered one. But that may have been available before…)
> 
> In any case, I have added a reference to our reading list[1]
> 
> Thanks!
> 
> Ivan
> 
> 
> [1] https://github.com/w3c/publ-wg/wiki/Reading-List
> 
> 
> 
>> On 25 Oct 2017, at 16:33, Heather Flanagan (RFC Series Editor) <rse@rfc-editor.org> wrote:
>> 
>> Hello all,
>> 
>> Thought this new RFC, on the standards track within the IETF, might be of interest.
>> -Heather
>> 
>> -------- Forwarded Message --------
>> Subject: RFC 8288 on Web Linking
>> Date: Tue, 24 Oct 2017 16:25:35 -0700 (PDT)
>> From: rfc-editor@rfc-editor.org
>> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
>> CC: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org
>> 
>> A new Request for Comments is now available in online RFC libraries.
>> 
>>         
>>         RFC 8288
>> 
>>         Title:      Web Linking 
>>         Author:     M. Nottingham
>>         Status:     Standards Track
>>         Stream:     IETF
>>         Date:       October 2017
>>         Mailbox:    
>> mnot@mnot.net
>> 
>>         Pages:      24
>>         Characters: 50797
>>         Obsoletes:  RFC 5988
>> 
>>         I-D Tag:    draft-nottingham-rfc5988bis-08.txt
>> 
>>         URL:        
>> https://www.rfc-editor.org/info/rfc8288
>> 
>> 
>>         DOI:        10.17487/RFC8288
>> 
>> This specification defines a model for the relationships between
>> resources on the Web ("links") and the type of those relationships
>> ("link relation types").
>> 
>> It also defines the serialisation of such links in HTTP headers with
>> the Link header field.
>> 
>> This is now a Proposed Standard.
>> 
>> STANDARDS TRACK: This document specifies an Internet Standards Track
>> protocol for the Internet community, and requests discussion and suggestions
>> for improvements.  Please refer to the current edition of the Official
>> Internet Protocol Standards (
>> https://www.rfc-editor.org/standards
>> ) for the 
>> standardization state and status of this protocol.  Distribution of this 
>> memo is unlimited.
>> 
>> This announcement is sent to the IETF-Announce and rfc-dist lists.
>> To subscribe or unsubscribe, see
>>   
>> https://www.ietf.org/mailman/listinfo/ietf-announce
>> 
>>   
>> https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
>> 
>> 
>> For searching the RFC series, see 
>> https://www.rfc-editor.org/search
>> 
>> For downloading RFCs, see 
>> https://www.rfc-editor.org/retrieve/bulk
>> 
>> 
>> Requests for special distribution should be addressed to either the
>> author of the RFC in question, or to 
>> rfc-editor@rfc-editor.org
>> .  Unless
>> specifically noted otherwise on the RFC itself, all RFCs are for
>> unlimited distribution.
>> 
>> 
>> The RFC Editor Team
>> Association Management Solutions, LLC
>> 
>> 
>> 
> 
> 
> ----
> Ivan Herman, W3C 
> Publishing@W3C Technical Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> ORCID ID: http://orcid.org/0000-0003-0782-2704
>

Received on Friday, 27 October 2017 17:09:19 UTC