[apps-discuss] Feedback on draft-wilde-profile-link-00

[Mark Nottingham <[e-mail]>]

<http://tools.ietf.org/html/draft-wilde-profile-link-00>

Overall, I'm really happy to see this draft; have been considering doing something along these lines too.

That said:


*** Major issues

* "Resource Profiles" - this spec defines the profile is being about the *resource* of its context. This is too loose; in HTML and other uses I've seen, profiles are about the *representation* they occur within.

In other words, the common idea of a profile, IME, is that it describes the conventions, extensions, etc. that are used in a particular document, but it doesn't say anything about the resource that the document was retrieved from.

That's a good design, because link relations are already a defined mechanism to talk about resource behaviours; having two such mechanisms isn't a good idea (at least without some discussion).

E.g., when I interact with a resource, I know it supports particular behaviours, because it's been linked to with relation "Foo." When I get a representation from the "Foo" resource, it will have a media type that describes the format, and also a profile ("Bar") that describes additional features / conventions of that document (such as a particular use of JSON or XML), but that profile won't -- and shouldn't! -- be an additional way of describing the behaviours of the "Foo" resource.



*** Nits / minor feedback:

* """This link relation type is independent of the resource representation it is used in (but the representation must support types links for this mechanism to work)"""

I'd state this in terms of "context", as per the link RFC.


* s/must support types links/must support typed links/


* """
   In fact, for the purpose of this
   specification, the URI does not necessarily have to link to a
   dereferencable resource, and clients can treat the occurrence of a
   specific URI in the same sense as a namespace URI and invoke specific
   behavior based on the assumption that a specific profile URI signals
   that a resource follows a specific profile.
"""

Here, I'd state this in terms of "target URIs", as does the link RFC.


* Your Security Considerations section isn't going to pass muster; if it were me, I'd talk about how software shouldn't make security-sensitive assumptions based upon profiles.


*"""
   As one example, consider the case of podcasts, a specific kind of
   feed using additional fields for media-related metadata.  Using a
   'profile' link, it would be possible for a client to understand that
   a specific feed is supposed to be a podcast feed, and that it may
   contain entries using podcast-specific fields.  This may allow a
   client to behave differently when handling such a feed (such as
   rendering a UI), even when the current set of entries in the feed may
   not contain any podcast entries.
"""

This is an interesting use case. My use cases for "profile" tend to be things like "links that this document contain follow *this* convention". More examples would be good.

Cheers,

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