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

From: Mark Nottingham <[email-masked]>
Date: Thu, 5 Apr 2012 11:25:01 -0500

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

---

From: Erik Wilde <[email-masked]>
Date: Fri, 06 Apr 2012 12:18:04 -0700

hello mark.

thanks a lot for the feedback! i am cross-posting this response to 
[email-masked], because it may be interesting for that 
community as well. too bad that the IETF drafts don't have commenting 
support on the IETF page itself, that would be really useful!

> * "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…

actually, most of the abstract talks about the profile qualifying a 
representation, but you're correct that this should be made very clear, 
and that it should be about the specific representation containing the 
profile link. i'll rewrite all the places where the text says that 
profiles are about resources.

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

yes, that is how it should be. only that i really would not want to say 
"describes" here, to clearly avoid the expectation that a 'profile' link 
MUST resolve to some sort of description. i'd say it "identifies" 
conventions, extensions, etc., and the only dependable operation on a 
'profile' link is to compare the URI to known profile URIs.

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

now i am little bit confused. taking your example, i am not concerned 
with the link relation that was used to discover 'foo' at all. all i am 
concerned with is that if i am retrieving 'foo' and i find a 'bar' 
profile identifier in the representation, i know that it follows 
constraints and conventions beyond the 'foo' media type. one example i 
am currently considering adding is atompub. currently, when you retrieve 
a feed, there's no way to tell it's atompub-capable just by looking at 
it. that could be easily remedied by adding a 'profile' link identifying 
the support of atompub. that's the kind of scenario i have in mind, but 
it sounds to me you're thinking about something else, or am i just 
misunderstanding you?

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

"This link relation type is independent of the context in which it is 
used (however, the representation must support typed links for this 
mechanism to work)"

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

done.

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

"In fact, for the purpose of this specification, the target URI does not 
necessarily have to identify a dereferencable resource (or even use a 
dereferencable URI scheme), and clients can treat the occurrence of a 
specific URI in the same way as an XML namespace URI and invoke specific 
behavior based on the assumption that a specific profile target URI 
signals that a resource representation follows a specific profile."

> * 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.

any specific suggestions on how to phrase that? ;-)

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

to me, it's both about those links and about conventions followed in the 
document itself. i am currently planning to include three examples in 
the next version of the draft:

- HCard
- Dublin Core
- AtomPub

particularly this last one might be what you're looking for, right? if 
you have any suggestions what to add to this list, please let me know.

thanks a lot for the feedback! i'll continue working on the examples, 
and as soon as these are finished, i am planning to publish -01 and see 
whether the additional examples make it easier to understand what this 
draft is trying to accomplish, and there might be more feedback.

cheers and happy easter everybody,

dret.

-- 
erik wilde | mailto:[email-masked]  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 10 Apr 2012 10:56:22 -0500

On 06/04/2012, at 2:18 PM, Erik Wilde wrote:

> now i am little bit confused. taking your example, i am not concerned with the link relation that was used to discover 'foo' at all. all i am concerned with is that if i am retrieving 'foo' and i find a 'bar' profile identifier in the representation, i know that it follows constraints and conventions beyond the 'foo' media type.

Yup.

> one example i am currently considering adding is atompub. currently, when you retrieve a feed, there's no way to tell it's atompub-capable just by looking at it.

Well, what thing in this case is atom pub capable? The format that the links are occurring within, or the targets of the links themselves? I'd argue the latter. You can take that argument too far, of course, but generally I see profiles as describing format conventions, and link relations as describing behaviours of resources. Of course, some of those behaviours can be "produce this format" and some of the formatting conventions can be "link to something with this behaviour".

Am happy to be proven wrong on this, I just think we need good patterns of use / best practices to encourage reasonable design.

Make sense?

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

---

From: Jan Algermissen <[email-masked]>
Date: Tue, 10 Apr 2012 20:58:48 +0200

> > one example i am currently considering adding is atompub. currently, when you retrieve a feed, there's no way to tell it's atompub-capable just by looking at it.

The thing is that it is not necessary to *learn* this. If it is your expectation that the service you are interacting with is actually an atompub service then fine, go ahead. If the service behaves as you expect, fine; your use case succeeds.

If it isn't you'll discover that from the response and change configuration of your set of entry URIs or whatever.

The decision regarding your use case comes first and you do not need to double check at runtime. For example, you have a bookmark for your favorite search engine. Do you check every time you use that bookmark whether the search engine is still there? Or do you just use the bookmark based according to your expectations?

Likewise, what does that check for atompub capabilities buy you? The reason you check for them is that you assume they are there in the first place. If that check fails .... then what? You are in exactly the same situation as when you POST you atom entry right away and see what happens.

The nature (as in "Amazon is an online store") of services changes slowly (if at all) and the particular HTTP idioms that services use also changes slowly (e.g. creation with PUT vs. creation with POST). In REST there is, IMHO at least, a third xxx-time besides the traditional design-time and run-time. It is what I think of as 'configuration-time'. This is where a method like OPTIONS plays its part, for example. Try out a service once, learn what it is and what its particularities are and then adjust your configuration for interactions with that service. The things you discover at configuration-time are not likely to change soon. If they do, you adjust your configuration and maybe you do not need to do that , ever.

> Am happy to be proven wrong on this, I just think we need good patterns of use / best practices to encourage reasonable design.

+1

Jan

---

From: Erik Wilde <[email-masked]>
Date: Wed, 11 Apr 2012 22:19:32 -0700

hello jan.

> Likewise, what does that check for atompub capabilities buy you? The reason you check for them is that you assume they are there in the first place. If that check fails .... then what? You are in e…

the idea is to be able to check for the profile URI to see whether a 
feed i have discovered supports atompub or not. if it does, i might show 
an "upload" feature in a UI that otherwise i would not show. without the 
feed advertising its capabilities, i cannot know, and i certainly don't 
want to create a fake post to test whether atompub is supported or not.

if all operations in atompub were exposed via links, it would be a 
different story in this particular case, but they are not, so a profile 
URI would be one way to go. and it's just one example and not the whole 
'profile' story.

cheers,

dret.

---

From: Erik Wilde <[email-masked]>
Date: Wed, 11 Apr 2012 22:36:20 -0700

hello mark.

thanks for the comments!

>> now i am little bit confused. taking your example, i am not concerned with the link relation that was used to discover 'foo' at all. all i am concerned with is that if i am retrieving 'foo' and i…

good to see we're in basic agreement.

> Well, what thing in this case is atom pub capable? The format that the links are occurring within, or the targets of the links themselves? I'd argue the latter. You can take that argument too far,…

with atompub i think you're right about 'edit' links in entries, so if i 
aggregate atompub-capable feeds, then my aggregate feed may not be 
atompub-capable, but the entries may very well be. but if my feed is 
indeed able to accept POST requests to create new entries, then there 
simply is no link to represent that fact, and a profile URI would be one 
way to represent that capability in the feed itself.

while i see your point about profile more being about format conventions 
(this is where HTML started this idea, and in that case my podcast 
example might better fit your bill), i think eventually the line between 
format conventions and behavior is fuzzy. maybe the best way for me to 
go forward is to finish the examples section, and then we can start more 
concrete discussions whether this would be the kind of scenario we'd 
like to encourage for 'profile' links.

dret.

---

From: Jan Algermissen <[email-masked]>
Date: Thu, 12 Apr 2012 09:12:13 +0200

Hi Erik,

On Apr 12, 2012, at 7:19 AM, Erik Wilde wrote:

> the idea is to be able to check for the profile URI to see whether a feed i have discovered supports atompub or not. if it does, i might show an "upload" feature in a UI that otherwise i would not show. without the feed advertising its capabilities, i cannot know, and i certainly don't want to create a fake post to test whether atompub is supported or not.

Ok (though I personally would not see a profile as saying something about the resource, but about the payload)

Anyhow - have you considered supporting your use case with the 'service' link relation? The pointed-to service document would tell your UA, what resource are app-collections.

(BTW, seems the registry is broken there, because service cites atompub as its spec - which it is not).

Jan

> 
> if all operations in atompub were exposed via links, it would be a different story in this particular case, but they are not, so a profile URI would be one way to go. and it's just one example and not the whole 'profile' story.
> 
> cheers,
> 
> dret.
> 
> --

---

From: Julian Reschke <[email-masked]>
Date: Thu, 12 Apr 2012 17:49:46 +0200

On 2012-04-12 09:12, Jan Algermissen wrote:
> ...

Right; that would be consistent with the use of the profile attribute in 
HTML4.

> (BTW, seems the registry is broken there, because service cites atompub as its spec - which it is not).

Indeed, let's blame Mark for this :-)

Seems we need a spec for "service" then.

best regards, Julian

---

From: Erik Wilde <[email-masked]>
Date: Thu, 12 Apr 2012 09:06:11 -0700

hello.

> Indeed, let's blame Mark for this :-)

yup, that occurred to me a while ago when i was looking for a spec for 
the "registered" 'service' relation and there was none, but back then, 
nobody seemed to think that was an issue that needed fixing. i think it 
would be good to have an actual spec (just out of curiosity it would be 
interesting to know how this value was able to creep in there without 
being spec'ed or reviewed a la rfc5988), and since i am in spec writing 
mode these days, i could easily get a 'service' one started. however, 
since this one would likely update rfc5023, i'd suggest to maybe also 
(if we can get agreement around this) include a 'profile' URI, assuming 
that there is some agreement on the 'profile' concept and that it would 
make sense for signaling that "an atom feed is following the atompub 
profile".

cheers,

dret.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 12 Apr 2012 11:09:37 -0500

IIRC that one and a few other ones got in while it was the Atom link relation registry, which was FCFS (no spec required).

Cheers,

On 12/04/2012, at 11:06 AM, Erik Wilde wrote:

> yup, that occurred to me a while ago when i was looking for a spec for the "registered" 'service' relation and there was none, but back then, nobody seemed to think that was an issue that needed fixing. i think it would be good to have an actual spec (just out of curiosity it would be interesting to know how this value was able to creep in there without being spec'ed or reviewed a la rfc5988), and since i am in spec writing mode these days, i could easily get a 'service' one started. however, since this one would likely update rfc5023, i'd suggest to maybe also (if we can get agreement around this) include a 'profile' URI, assuming that there is some agreement on the 'profile' concept and that it would make sense for signaling that "an atom feed is following the atompub profile".
> 
> cheers,
> 
> dret.
> 
> -- 

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

---

From: Julian Reschke <[email-masked]>
Date: Thu, 12 Apr 2012 18:10:22 +0200

> being spec'ed or reviewed a la rfc5988), and since i am in spec writing

Well, because it was in the Atom link relation registry before RFC 5988 
was approved.

> make sense for signaling that "an atom feed is following the atompub

Not sure about that.

It seems you are using "profile" in a very different way then it was 
used in HTML4; is this really a good idea?

Best regards, Julian

---

From: Erik Wilde <[email-masked]>
Date: Thu, 12 Apr 2012 09:24:24 -0700

hello jan.

> Ok (though I personally would not see a profile as saying something about the resource, but about the payload)

yes, we have agreement on this. a profile (quoting from the -01 text i 
am writing now) "are additional semantics that can be used to process a 
resource  representation, such as constraints, conventions, extensions, 
or any other aspects that do not alter the basic media type semantics."

if a feed indicates it supports atompub, that extends what to expect in 
the feed, and in case of atompub, it also extends the feed's behavior. 
like i said in a response to mark, i think the line between "format 
conventions" and "behavior" is fuzzy. but i'd argue that the 'atompub 
profile' definitely would be specific for the representation (the 
atompub enabled feed), because a different representation of the 
collection resource might very well expose a different mechanism to 
provide write access to the collection.

cheers,

dret.

---

From: Erik Wilde <[email-masked]>
Date: Thu, 12 Apr 2012 09:39:27 -0700

hello julian.

> used in HTML4; is this really a good idea?

i certainly do not intend to use it in a different way, because like 
you, i do not think that would be a good idea. my current definition is 
that "a profile are additional semantics that can be used to process a 
resource representation, such as constraints, conventions, extensions, 
or any other aspects that do not alter the basic media type semantics."

my understanding of HTML's profile was always like this. quoting from 
http://www.w3.org/TR/html4/struct/global.html#profiles :

"User agents may be able to recognize the name (without actually 
retrieving the profile) and perform some activity based on known 
conventions for that profile. For instance, search engines could provide 
an interface for searching through catalogs of HTML documents, where 
these documents all use the same profile for representing catalog entries."

mark also noted that he regards a profile mostly as saying something 
about a representation's content, such as a metadata profile in HTML, 
saying that the web page uses dublin core. but even when you look at the 
dublin core HTML profile (http://dublincore.org/documents/dcq-html/), it 
also defines conventions about links 
(http://dublincore.org/documents/dcq-html/#sect-2-4), and not just about 
non-link data. which is the point i was trying to make saying that the 
line between "format extensions" and "links" is fuzzy: essentially, a 
link *is* a format extension, only one that extends beyond the current 
resource.

i am not sure i was able to fully address your concerns, so if you still 
think i am "redefining" what 'profile' is supposed to do, could you be a 
bit more specific why you think that's the case, and how you'd like to 
see it done?

thanks a lot and cheers,

dret.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 12 Apr 2012 18:52:35 +0200

> bit more specific why you think that's the case, and how you'd like to

Maybe we need to switch to examples to get a clearer picture.

With "profile" I understand that the link *target* is a URI describing 
the profile, such as <http://www.w3.org/2006/03/hcard> which describes 
that hcard profile.

If you want to use the profile link relation to declare that something 
is a an AtomPub server, on which resource would you set the link relation?

Best regards, Julian

---

From: Erik Wilde <[email-masked]>
Date: Thu, 12 Apr 2012 10:26:54 -0700

hello julian.

> the profile, such as <http://www.w3.org/2006/03/hcard> which describes

no, the 'profile' link target URI *identifies* the profile in use, and 
it MAY point to a description (and hopefully will), but it does not have 
to do that. at that level it works exactly the same as XML namespace 
URIs: its definition is to be an identifier, but if you want to be nice, 
then you actually link to some description, but that's entirely up to 
you. here's what the draft currently says:

"Profiles are identified by URI, but as with for example XML namespace 
URIs, the URI in this case first and foremost serves as an identifier, 
meaning that the presence of a specific URI has to be sufficient for a 
client to assert that a resource representation conforms to a profile."

> is a an AtomPub server, on which resource would you set the link relation?

the feed served by the atompub-enabled server would contain such a 
'profile' link on the feed level, indicating to a client that it can 
POST to that feed's URI to create a new collection member.

cheers,

dret.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 12 Apr 2012 19:40:19 +0200

> to do that. at that level it works exactly the same as XML namespace

Yes, sorry for being not precise.

> POST to that feed's URI to create a new collection member.

OK. I don't have a problem with that. The one thing to consider is, as 
others have pointed out, whether it would make sense to use "service" 
instead and let that point back to the same URI (assuming we have a 
proper definition of "service" :-)

Best regards, Julian

---

From: Erik Wilde <[email-masked]>
Date: Thu, 12 Apr 2012 11:00:47 -0700

hello julian.

> proper definition of "service" :-)

so i guess the difference here is the following:

- 'profile' would just say that a feed is atompub-enabled, but it would 
not allow you to discover the specific service description for that 
feed. it would just be a link to discover and understand that i can POST 
to that URI.

- 'service' would link to the specific service description for that 
feed, and thus must be a working link and would allow clients to find 
out more about the service provided by the atompub server.

to be honest, i just looked at "naked atompub" and thought 'profile' 
might be a good thing and a good example for the 'profile' spec. if we 
assume "atompub + 'service'" is being used, then maybe 'profile' is of 
little additional value, and i should stop using it as an example.

which (and now i am happily cross-posting to [email-masked] as 
well) leads me to the question: should we have a 'service' spec or are 
we happy with 'service' just magically showing up in the registry? as 
somebody just reading and implementing atompub right now, there's no way 
for me to find out about 'service', so i think it should be properly 
spec'ed. if people agree (feedback from [email-masked] would be 
very welcome), i'd be happy to come up with a first draft.

cheers,

dret.

---

From: Erik Wilde <[email-masked]>
Date: Sun, 15 Apr 2012 21:32:01 +0200

hello.

"The 'profile' Link Relation Type" is now available as version 01 
(draft-wilde-profile-link-01) at 
http://tools.ietf.org/html/draft-wilde-profile-link. the changes are 
listed at 
http://tools.ietf.org/html/draft-wilde-profile-link-01#section-7.1, with 
the main changes being a bigger section with some examples, and the text 
in general has been revised to make it clear that profiles relate to 
representations (the ones they are found in) and not to resources.

thanks for all the feedback so far, more feedback would be very welcome, 
and should you happen to be at www2012 this coming week, say hello and 
let me know what you think about 'profile' links!

cheers,

dret.

---

From: Goix Laurent Walter <[email-masked]>
Date: Mon, 16 Apr 2012 05:45:51 +0200

Hello erik,

Thanks for the update.
Such types of link have also been widely used for years together with the webfinger specification (usually under the http://webfinger.net/rel/profile-page rel type for html profile pointers) so I would suppose it will also relate to the wf/swd discussion and that ultimately this draft becomes compatible with the discovery solution ultimately specified. It may be worth adding it as an example.

I would also suggest to emphasize the usage on the "type" attribute together with this link rel to better characterize the type of information a client should expect. Indeed I would expect in some cases more than one of such "profile" link rel to be published within the same document, and the type may be useful for this. E.g. so far in wf the http://webfinger.net/rel/profile-page and http://microformats.org/profile/hcard (and to some extent the http://portablecontacts.net/spec/1.0#me) rel types are widely used to discriminate the expect type of "profile" format/info accessible. It would be valuable to maintain such flexibility.

walter

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Erik Wilde
Inviato: lunedì 16 aprile 2012 2.32
A: REST Discuss; application-layer protocols
Oggetto: [apps-discuss] draft-wilde-profile-link-01 published

hello.

cheers,

dret.

--
erik wilde | mailto:[email-masked]  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |
_______________________________________________
apps-discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

---

From: Erik Wilde <[email-masked]>
Date: Mon, 16 Apr 2012 07:46:15 +0200

hello walter.

> Such types of link have also been widely used for years together with the webfinger specification (usually under the http://webfinger.net/rel/profile-page rel type for html profile pointers) so I w…

thanks for the pointer to web finger. i am sure there are quite a number 
of other formats out there using html profiles, maybe it would be 
interesting to create a small list of "well-known" profiles.

> I would also suggest to emphasize the usage on the "type" attribute together with this link rel to better characterize the type of information a client should expect. Indeed I would expect in some…

while i think that the "type" idea is interesting, i am confused that 
you suggest http://microformats.org/profile/hcard as such a type. 
afaict, hCard is a specific profile and does not define a format for 
describing profiles. i would expect types to define a framework that 
could be used to define specific profiles, but maybe we have a different 
idea of what a "type" attribute could do? could you explain why you 
consider http://microformats.org/profile/hcard to be a type instead of a 
specific profile?

thanks and cheers,

dret.

---

From: Goix Laurent Walter <[email-masked]>
Date: Mon, 16 Apr 2012 08:07:45 +0200

Hello erik,
[snip]
>
> > Thanks for the update.
> > Such types of link have also been widely used for years together with
> the webfinger specification (usually under the
> http://webfinger.net/rel/profile-page rel type for html profile
> pointers) so I would suppose it will also relate to the wf/swd
> discussion and that ultimately this draft becomes compatible with the
> discovery solution ultimately specified. It may be worth adding it as
> an example.
>
[walter] some work in that direction has been already recorded here [1] that you may want to check

>
> > I would also suggest to emphasize the usage on the "type" attribute
> together with this link rel to better characterize the type of
> information a client should expect. Indeed I would expect in some cases
> more than one of such "profile" link rel to be published within the
> same document, and the type may be useful for this. E.g. so far in wf
> the http://webfinger.net/rel/profile-page and
> http://microformats.org/profile/hcard (and to some extent the
> http://portablecontacts.net/spec/1.0#me) rel types are widely used to
> discriminate the expect type of "profile" format/info accessible. It
> would be valuable to maintain such flexibility.
>
[walter] maybe i wasn't clear enough I apologize. I was indeed referring to the "type" attribute/parameter of the "link" element/header, which is already defined both in RFC5988 and in XRD for referencing the media-type associated with that link. In that sense an hcard link rel would typically be "text/html" whilst a poco#me representation of the "profile" link could be "application/json".
However I do understand that this may not be enough for correctly characterizing the format of the specific profile information: how would I indicate in fact that this "profile" link/web page is hcard-enabled or not a priori? Same for json: poco is a popular json format for representing profile info but may not be the only one.
My point is I may have the following xrd at this stage with the profile rel links:
<Link rel="profile" type="text/html" href="http://example.com/profiles/joe" />
<Link rel="profile" type="text/html" href="http://example.com/profiles/joe/hcard" />
<Link rel="profile" type="application/json" href="http://example.com/profiles/joe/poco" />
...without any clear view on which "profile" provides which format.
I hope I have clarified my point here and welcome your feedback on this.

walter

[1] http://www.packetizer.com/webfinger/link_relations.html

---

From: Erik Wilde <[email-masked]>
Date: Mon, 16 Apr 2012 09:10:48 +0200

hello walter.

> [walter] some work in that direction has been already recorded here [1] that you may want to check

these are link relation types and not profile identifiers, right? i am 
a bit concerned to see expected media types encoded in link relations, 
for example i'd prefer to see a "contact" link type and then getting a 
vCard or an xCard or HTML-embedded hCard is up to conneg and thus a 
runtime issue. doing it that way frees you from having to mint new link 
relation types when you want to support new media types (what about FoaF 
contact info, for example?).

> [walter] maybe i wasn't clear enough I apologize. I was indeed referring to the "type" attribute/parameter of the "link" element/header, which is already defined both in RFC5988 and in XRD for refe…

and that doesn't really help at all. for it to be helpful, the profile 
description language would need to have a media type, and then you could 
identify it by that. and generally speaking, a 'profile' link should not 
need to be dereferenced to be useful, it's an identifier. that also 
means that designing an environment where runtime lookup of the profile 
description is necessary would be a violation of the spec, because 
clients would not be able to "understand" that the meaning of a profile 
URI changes over time. this almost automatically means that any updates 
in the profile need to done by minting a new profile URI, and if it is 
done backwards compatible, then representations conforming to the new 
profile should list both profile versions:

<link rel="profile" href="http://microformats.org/profile/hcard"/>
<link rel="profile" href="http://microformats.org/profile/hcard/2.0"/>

> However I do understand that this may not be enough for correctly characterizing the format of the specific profile information: how would I indicate in fact that this "profile" link/web page is hc…

if there is a format for describing profile information, then it should 
have a media type and then web clients can use that media type. just 
referring to it as JSON is not very helpful. but even if there was such 
a media type, it would not change the fact that the way how 'profile' is 
drafted right now, runtime access to profile descriptions is not part of 
the design; clients compare supported profile URIs to the profiles they 
find in a representation, and then decide what to do.

> I hope I have clarified my point here and welcome your feedback on this.

now i am getting the impression that you're having some misconceptions 
about profile. profile links are not intended to link to particular 
resource that contains data of interest to the client. in your example, 
the page would be about joe, and joe might decide to embed his 
information using hcard, and then the page would say

<link rel="profile" href="http://microformats.org/profile/hcard"/>

and clients could extract joe's hcard info from the page without ever 
accessing http://microformats.org/profile/hcard; they would simply see 
that URI and then, if they supported hCard, understand that the page 
contain embedded hCard information.

i hope that clarifies things a bit. cheers,

dret.

---

From: Goix Laurent Walter <[email-masked]>
Date: Thu, 19 Apr 2012 05:34:13 +0200

Thank you erik for your clarifications. Indeed my first reading of the draft was biased into another understanding of the "profile" keyword, related to user/resource "profile" representation format. I have now clear that this is not the purpose of this draft.

As I understand it now his link type is thus to be typically included in the documents themselves to better describe their own format (just like the html "profile" you mentioned).

I am biased by the current discussion/activity going on wrt resource discovery (see thread on webfinger vs swd) that relies on "similar" links within a descriptor to "discover" endpoints of certain types to access different information related to a user. One of these links which is quite popular is the "http://webfinger.net/rel/profile-page" that links to a user profile description, but that doesn't indicate "your" type of profile. In other words that type of link does not allow you to know in advance whether that page contains hcard information or others. In the discovery use case this is useful as based on that information I could avoid accessing that endpoint (and read the "profile" link type in it) to understand the specific type/format of information it contains.

walter

> Da: Erik Wilde [mailto:[email-masked]]
> Inviato: lunedì 16 aprile 2012 14.11
> A: Goix Laurent Walter
> Cc: REST Discuss; application-layer protocols
> Oggetto: Re: draft-wilde-profile-link-01 published
>
> hello walter.
>
> > [walter] maybe i wasn't clear enough I apologize. I was indeed
> referring to the "type" attribute/parameter of the "link"
> element/header, which is already defined both in RFC5988 and in XRD for
> referencing the media-type associated with that link. In that sense an
> hcard link rel would typically be "text/html" whilst a poco#me
> representation of the "profile" link could be "application/json".
>
> > However I do understand that this may not be enough for correctly
> characterizing the format of the specific profile information: how
> would I indicate in fact that this "profile" link/web page is hcard-
> enabled or not a priori? Same for json: poco is a popular json format
> for representing profile info but may not be the only one.
>
> > <Link rel="profile" type="text/html"
> href="http://example.com/profiles/joe" />
> > <Link rel="profile" type="text/html"
> href="http://example.com/profiles/joe/hcard" />
> > <Link rel="profile" type="application/json"
> href="http://example.com/profiles/joe/poco" />