Re: [link-relations] NEW RELATION: collection

[Mykyta Yevstifeyev <[e-mail]>]

06.08.2011 12:03, mike amundsen wrote:
> 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?

There is no problem to place both rel types specifications in one I-D.

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: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
>>