Subject: [link-relations] NEW APP DATA

From: Ian Hickson <[email-masked]>
Date: Wed, 14 Jul 2010 23:13:46 +0000 (UTC)

o  Application Name: HTML
   o  Description: Allowed on <a> and <area>?
   o  Default Value: No
   o  Notes: The following values should have "Yes" for this field:
        alternate, appendix, bookmark, chapter, contents, copyright,
        first, glossary, help, index, first [sic - it's listed
        twice?], last, license, next, prev, previous, section, start,
        subsection, up

   o  Application Name: HTML
   o  Description: Allowed on <link>?
   o  Default Value: No
   o  Notes: The following values should have "Yes" for this field:
        alternate, appendix, chapter, contents, copyright, first,
        glossary, help, index, first [sic - it's listed twice?], last,
        license, next, prev, previous, section, start, subsection, up

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 15 Jul 2010 10:36:02 +1000

Hi Ian,

Can you give a link back to where you specify these in HTML5?

Cheers,

On 15/07/2010, at 9:13 AM, Ian Hickson wrote:

> _______________________________________________
> link-relations mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/link-relations

--
Mark Nottingham     http://www.mnot.net/

---

From: Ian Hickson <[email-masked]>
Date: Thu, 15 Jul 2010 07:54:08 +0000 (UTC)

> Can you give a link back to where you specify these in HTML5?

It's not specified in HTML5 at all yet since there's nothing to point to. 
Currently HTML5 uses its own registry which has this built-in. It's not 
clear to me how I would specify this without the registry having the field 
defined. Could you elaborate on what you are looking for?

The registration process doesn't mention a specification requirement, so 
I'm not sure exactly what to provide here.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 15 Jul 2010 10:14:04 +0200

On 15.07.2010 09:54, Ian Hickson wrote:
> ...
> ...

<http://greenbytes.de/tech/webdav/draft-nottingham-http-link-header-10.html#rfc.section.6.3>:

    Application data is registered on the advice of a Designated Expert
    (appointed by the IESG or their delegate), with a Specification
    Required (using terminology from [RFC5226]).

<http://tools.ietf.org/html/rfc5226#section-4.1>:

       Specification Required - Values and their meanings must be
             documented in a permanent and readily available public
             specification, in sufficient detail so that interoperability
             between independent implementations is possible.  When used,
             Specification Required also implies use of a Designated
             Expert, who will review the public specification and
             evaluate whether it is sufficiently clear to allow
             interoperable implementations.  The intention behind
             "permanent and readily available" is that a document can
             reasonably be expected to be findable and retrievable long
             after IANA assignment of the requested value.  Publication
             of an RFC is an ideal means of achieving this requirement,
             but Specification Required is intended to also cover the
             case of a document published outside of the RFC path.  For
             RFC publication, the normal RFC review process is expected
             to provide the necessary review for interoperability, though
             the Designated Expert may be a particularly well-qualified
             person to perform such a review.

             Examples: Diffserv-aware TE Bandwidth Constraints Model
             Identifiers [RFC4124], TLS ClientCertificateType Identifiers
             [RFC4346], ROHC Profile Identifiers [RFC4995].

---

From: Ian Hickson <[email-masked]>
Date: Wed, 21 Jul 2010 21:03:52 +0000 (UTC)

>             [RFC4346], ROHC Profile Identifiers [RFC4995].

It's not clear to me if the quotes above were intended to answer my 
question or were just helpful background, but since no other reply has 
been forthcoming, I should reiterate that I have no idea what is needed as 
part of the registration of fields in terms of a specification.

Would an equivalent of this section but for this registry be suitable?:

   http://www.whatwg.org/specs/web-apps/current-work/complete.html#other-link-types

Any help would be most welcome. I thought I had completed the template as 
described in the "Link Relation Application Data Registry" section.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 21 Jul 2010 23:22:53 +0200

> question or were just helpful background, but since no other reply has

You asked about where the specification requirement was, and I pointed 
to that text.

> described in the "Link Relation Application Data Registry" section.

What's needed is a stable spec that defines the two flags you want to 
register, and a URI for that spec.

Best regards, Julian

---

From: Ian Hickson <[email-masked]>
Date: Wed, 21 Jul 2010 23:02:34 +0000 (UTC)

It's hard to know exactly what you want since the registry has no 
examples.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 22 Jul 2010 07:11:27 +0200

> It's hard to know exactly what you want since the registry has no

I don't understand what you mean by "equivalent of this section but for 
this registry".

What's needed is referenceable text that fully describes the metadata 
you want to add to the link relations registry. Yes, that can be a 
section within a larger spec (if this was your question).

In particular it should have sufficient detail so that people defining 
new link relations can understand what to set the value to. So, for 
example, in this case it would need to answer why you would ever want to 
define a link relation and have it *not* allowed in an HTML <link> 
element (see 
<http://www.ietf.org/mail-archive/web/link-relations/current/msg00002.html>).

Best regards, Julian