Opened 11 years ago

Closed 11 years ago

#196 closed protocol enhancement (fixed)

Clarify URI fetching rule for attribute values in Section 3

Reported by: zach@… Owned by: zach@…
Priority: trivial Milestone:
Component: link-format Version:
Severity: - Keywords:
Cc:

Description

From Julian Reschke's review:

Section 3 currently has a MUST for treating values of attributes as non-retrievable identifiers. This ticket proposes to loosen that requirement and allow dereferencing (making it explicit that this is however not part of the protocol).

Proposed text change:

  1. CoRE link extensions

The following CoRE specific target attributes are defined in addition
to the ABNF rules in Section 5 of [RFC5988]. These attributes
describe information useful in accessing the target link of the
relation, and in some cases may be URIs. These URIs MUST be treated

s/may be/can use the syntactical form of a/

as non resolvable identifiers (they are not meant to be retrieved).

Not sure about the "MUST". Maybe replace with an explanation that they can indeed by dereferenced (for instance to obtain a description of the link relation), but that this is not part of the protocol and MUST NOT be done automatically on link evaluation.

Change History (1)

comment:1 Changed 11 years ago by zach@…

  • Resolution set to fixed
  • Status changed from new to closed

Done, updated text:

  1. CoRE link extensions

The following CoRE specific target attributes are defined in addition
to those already defined in [RFC5988]. These attributes describe
information useful in accessing the target link of the relation, and
in some cases can use the syntactical form of a URIs. Such a URI MAY
be dereferenced (for instance to obtain a description of the link
relation), but that this is not part of the protocol and MUST NOT be
done automatically on link evaluation. When attributes are compared,
they MUST be compared as strings. Relationships to resources that
are meant to be retrieved should be expressed as separate links using
the anchor attribute and the appropriate relation type.

Note: See TracTickets for help on using tickets.