Re: [link-relations] NEW RELATION: collection

[mike amundsen <[e-mail]>]

Mykyta:

Understood. I will work up the I-D document(s) this weekend and update
my application.

Should I write an I-D for each link rel type? or is it appropriate to
include both link rels in a single I-D?

mca
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf.rdf#me


#RESTFest 2011 - Aug 18-20
http://restfest.org



On Sat, Aug 6, 2011 at 04:42, Mykyta Yevstifeyev <[e-mail]> wrote:
> 06.08.2011 11:30, mike amundsen wrote:
>>
>> <quote>
>>>
>>> I'm trying to understand whether the intent for Opensearch's<Url>
>>>  element
>>> is to use the same relation names as, for instance, the HTTP Link header
>>> field.
>>
>> </quote>
>> Well, I really can't answer that Q. I included OpenSearch since it
>> _does_ use the same word as a rel value.
>>
>> <quote>
>>>
>>> In the past we have rejected requests that pointed to private domains.
>>
>> </quote>
>> Both values are logged here:
>> http://microformats.org/wiki/existing-rel-values#non_HTML_rel_values
>
> Mike,
>
> This link you point to here and below (I mean
> http://amundsen.com/media-types/linkrelations/registrations/) cannot be
> considered to be fine for RFC 5226 'Specification Required'.  I agree here
> with Julian that writing the Internet-Draft should be sufficient to perform
> registration; the template written by Julian is perfect to be used here.
>
> Mykyta
>
>>
>> mca
>> http://amundsen.com/blog/
>> http://twitter.com@mamund
>> http://mamund.com/foaf.rdf#me
>>
>>
>> #RESTFest 2011 - Aug 18-20
>> http://restfest.org
>>
>>
>>
>> On Sat, Aug 6, 2011 at 04:25, Julian Reschke<[e-mail]>
>>  wrote:
>>>
>>> On 2011-08-06 10:14, mike amundsen wrote:
>>>>
>>>> On Sat, Aug 6, 2011 at 04:00, Julian Reschke<[e-mail]>
>>>>  wrote:
>>>>>
>>>>> On 2011-08-06 09:30, mike amundsen wrote:
>>>>>>
>>>>>> Relation Name:
>>>>>> collection
>>>>>>
>>>>>> Description:
>>>>>> The target IRI points to a resource which represents a list of which
>>>>>> the context  IRI is a member.
>>>>>>
>>>>>> References:
>>>>>> http://www.opensearch.org/Specifications/OpenSearch/1.1#Url_rel_values
>>>>>> http://amundsen.com/media-types/maze/format/#link-relations
>>>>>> http://amundsen.com/media-types/collection/format/#link-relations
>>>>>>
>>>>>> Notes:
>>>>>> Logged with the Microformats Existing Rel Values.
>>>>>> The OpenSearch definition is different than that given above
>>>>>> ("Represents a request for a set of resources.")
>>>>>>
>>>>>> Application Data:
>>>>>> None
>>>>>
>>>>> A few questions:
>>>>>
>>>>> Is Opensearch using link relations in the RFC 5988 sense? That is, do
>>>>> they
>>>>> share the same space of names?
>>>>
>>>> Not sure of this question "share the same space of names"?
>>>
>>> I'm trying to understand whether the intent for Opensearch's<Url>
>>>  element
>>> is to use the same relation names as, for instance, the HTTP Link header
>>> field.
>>>
>>>>> Also, if this is a new relation name, wouldn't "contained-in" or
>>>>> something
>>>>> like that be more accurate? (yep, that's bikeshedding)
>>>>
>>>> yeah, might have been better. At this point I'd prefer to not amend the
>>>> name.
>>>>
>>>>> Finally:
>>>>>
>>>>>> http://amundsen.com/media-types/maze/format/#link-relations
>>>>>> http://amundsen.com/media-types/collection/format/#link-relations
>>>>>
>>>>> It would be great if there was a single document defining the link
>>>>> relation
>>>>> independently of a specific media type.
>>>>
>>>> I have a page that only lists the IANA-related link relations:
>>>> http://amundsen.com/media-types/linkrelations/registrations/
>>>>
>>>> I can split this into a single document for each relation type, if
>>>> that is the preferred approach.
>>>
>>> That might be good; but before that we probably should figure out first
>>> where this document should live  -- RFC 5988 requests "specification
>>> required", which in IETF-speak means:
>>>
>>>      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.
>>>
>>> In the past we have rejected requests that pointed to private domains.
>>>
>>> Any chance you could put the stuff into an Internet Draft? Template:
>>>
>>> <http://www.ietf.org/mail-archive/web/link-relations/current/msg00152.html>.
>>>
>>> Best regards, Julian
>>>
>> _______________________________________________
>> link-relations mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/link-relations
>>
>
> _______________________________________________
> link-relations mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/link-relations
>