Subject: [apps-discuss] High-level considerations about "webfinger"

From: Goix Laurent Walter <[email-masked]>
Date: Fri, 2 Nov 2012 13:02:28 +0100

Dear all,

I tried to catch up with the hot discussion of the last days and would try to hold on for the time of an email trying to summarize the current situation and take a breath...

At this stage we are having very distinct camps in the list for what they have in mind behind the "webfinger" keyword: xml vs json, 1 or 2 roundtrips, privacy ecc. It seems to me that Paul has been doing an outstanding work trying to compromise (I would have lost patience...) but such compromises do not seem to satisfy anyone: actually, compromises are moving more and more towards the original SWD idea at the end.

Maybe we could ask ourselves the following questions:

-          With the "xrd" idea in mind (please, jrd-enthusiasts, try to put that hat on as well), what is actually missing beyond rfc6415 for "webfinger"? now the 'acct' URI is a separate draft (an initial motivation). Rel/resource parameters for xrd supporters do not seem essential in my understanding neither. So (although I am a supports of that camp) I have trouble seeing what truly need to be added. I can understand Evan's position for keeping the entire xrd-based community (ostatus, diaspora, etc) but isn't rfc6415-compliance for those existing implementations already fair enough? If a new "webfinger" is jrd, 1-roundtrip only at the end it's just another rfc number to be referenced instead/in addition and as such has the same value...(not mentioning the implementation work needed)

-          Rfc6415-compliance & backward compatibility: this seems also contentious as whether backward-compatibility is needed or not. however the current "compromises" are odd in maintaining backward-compability. What is exactly interesting for "webfinger" from that rfc? From the latest alternative it seems only the "host-meta.json" endpoint name & the jrd. Or else? How these can be referenced at best without needing the whole thing?

-          Host-meta+lrdd vs new endpoint: Should we propose an alternative endpoint name (there were many proposals, including one of mine a while ago) so that we simply "distinguish" the existing host-meta+lrdd way from a new "webfinger" way/endpoint all-in-1-roundtrip. This is what swd is proposing. Eventually one could at the end use the same backend implementation to return queries coming all the way from host-meta+lrdd than others using another well-known (and direct) endpoint. This would also be much easier to support any query parameter (resource, rel, etc) as some are arguing against overriding host-meta with parameters. In that case the new "webfinger" would be actually more like SWD (with JRD support)

-          In alternative, what about the provocative idea from Evan to "replace" rfc6415? Are they other usages of rfc6415 than the "webfinger" one throughout the community? If yes, then it may be more difficult to replace unless agreed with whom is using it. Otherwise, as it seems most people do not like it, why keep it as-is and not upgrade directly to whatever is now useful? A standard that is not used is useless and has no point in being superseded by a parallel spec not actually obsoleting it... If JRD and the well-known endpoints are useful in other context, then why not splitting them from the actual protocol procedures of current rfc6415 and have clean specs that can be generically referenced without buying the full thing or writing complex text to select some parts of it and contest others: 1 for JRD and 1 for the endpoints/link registrations. Then a protocol-oriented spec like webfinger can easily decide what to take and replace current rfc6415, or decide to live separately/parallel.

Personally I have more interest and feeling for the 2-roundtrip xrd solution from rfc6415 still. But if I have to choose between an odd/partial/unstable/unclear/buggy reference to it and a new json way for satisfying another use case I have to put limits in compromising and at this point prefer a parallel/independent approach. Of course I'd like possibly to reuse the file format (jrd) as it seems suitable for all. At least this way rfc6415 can still live independently (being updated or not if we want to make it "cleaner") and "webfinger" can hopefully be finalized quickly in the json + 1 roundtrip direction...

Once these macro topics are clarified then we can better discuss the details about securing wf, supporting privacy, distinct delivery for auth/non-auth requests etc...But can we first discuss at high level what we want to achieve in terms of process?

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

Rispetta l'ambiente. Non stampare questa mail se non ? necessario.

---

From: Evan Prodromou <[email-masked]>
Date: Fri, 02 Nov 2012 11:04:37 -0400

The conversation has really moved on! I suggest you read Paul Jones's 
latest email to get caught up.

-Evan

On 12-11-02 08:02 AM, Goix Laurent Walter wrote:
>
> Dear all,
>
> I tried to catch up with the hot discussion of the last days and would 
> try to hold on for the time of an email trying to summarize the 
> current situation and take a breath...
>
> At this stage we are having very distinct camps in the list for what 
> they have in mind behind the "webfinger" keyword: xml vs json, 1 or 2 
> roundtrips, privacy ecc. It seems to me that Paul has been doing an 
> outstanding work trying to compromise (I would have lost patience...) 
> but such compromises do not seem to satisfy anyone: actually, 
> compromises are moving more and more towards the original SWD idea at 
> the end.
>
> -With the "xrd" idea in mind (please, jrd-enthusiasts, try to put that 
> hat on as well), what is actually missing beyond rfc6415 for 
> "webfinger"? now the 'acct' URI is a separate draft (an initial 
> motivation). Rel/resource parameters for xrd supporters do not seem 
> essential in my understanding neither. So (although I am a supports of 
> that camp) I have trouble seeing what truly need to be added. I can 
> understand Evan's position for keeping the entire xrd-based community 
> (ostatus, diaspora, etc) but isn't rfc6415-compliance for those 
> existing implementations already fair enough? If a new "webfinger" is 
> jrd, 1-roundtrip only at the end it's just another rfc number to be 
> referenced instead/in addition and as such has the same value...(not 
> mentioning the implementation work needed)
>
> -Rfc6415-compliance & backward compatibility: this seems also 
> contentious as whether backward-compatibility is needed or not. 
> however the current "compromises" are odd in maintaining 
> backward-compability. What is exactly interesting for "webfinger" from 
> that rfc? From the latest alternative it seems only the 
> "host-meta.json" endpoint name & the jrd. Or else? How these can be 
> referenced at best without needing the whole thing?
>
> -Host-meta+lrdd vs new endpoint: Should we propose an alternative 
> endpoint name (there were many proposals, including one of mine a 
> while ago) so that we simply "distinguish" the existing host-meta+lrdd 
> way from a new "webfinger" way/endpoint all-in-1-roundtrip. This is 
> what swd is proposing. Eventually one could at the end use the same 
> backend implementation to return queries coming all the way from 
> host-meta+lrdd than others using another well-known (and direct) 
> endpoint. This would also be much easier to support any query 
> parameter (resource, rel, etc) as some are arguing against overriding 
> host-meta with parameters. In that case the new "webfinger" would be 
> actually more like SWD (with JRD support)
>
> -In alternative, what about the provocative idea from Evan to 
> "replace" rfc6415? Are they other usages of rfc6415 than the 
> "webfinger" one throughout the community? If yes, then it may be more 
> difficult to replace unless agreed with whom is using it. Otherwise, 
> as it seems most people do not like it, why keep it as-is and not 
> upgrade directly to whatever is now useful? A standard that is not 
> used is useless and has no point in being superseded by a parallel 
> spec not actually obsoleting it... If JRD and the well-known endpoints 
> are useful in other context, then why not splitting them from the 
> actual protocol procedures of current rfc6415 and have clean specs 
> that can be generically referenced without buying the full thing or 
> writing complex text to select some parts of it and contest others: 1 
> for JRD and 1 for the endpoints/link registrations. Then a 
> protocol-oriented spec like webfinger can easily decide what to take 
> and replace current rfc6415, or decide to live separately/parallel.
>
> Personally I have more interest and feeling for the 2-roundtrip xrd 
> solution from rfc6415 still. But if I have to choose between an 
> odd/partial/unstable/unclear/buggy reference to it and a new json way 
> for satisfying another use case I have to put limits in compromising 
> and at this point prefer a parallel/independent approach. Of course 
> I'd like possibly to reuse the file format (jrd) as it seems suitable 
> for all. At least this way rfc6415 can still live independently (being 
> updated or not if we want to make it "cleaner") and "webfinger" can 
> hopefully be finalized quickly in the json + 1 roundtrip direction...
>
> Once these macro topics are clarified then we can better discuss the 
> details about securing wf, supporting privacy, distinct delivery for 
> auth/non-auth requests etc...But can we first discuss at high level 
> what we want to achieve in terms of process?
>
> Cheers
>
> walter
>
> 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./
>
> *rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se 
> non è necessario.*
>
>
>
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Goix Laurent Walter <[email-masked]>
Date: Fri, 2 Nov 2012 16:29:37 +0100

Hi evan,

I do have read the latest alt-r1 draft. But I do believe these are still applicable questions:

-          I could still see pros/cons in the list for rel/resource parameters in host-meta.json

-          The question of creating a new endpoint has been raised and still pending imo (also wrt previous bullet)

-          Relationship with rfc6415 is still not clear as some parts are clearly referenced (mostly procedures) whilst others mention a clear distance with it (eg xrd vs jrd). As a developer I could not know very well whether I need to implement rfc6415 and how much of it...at this point one may consider how much the draft gains in actually referencing those sections if it is to mandate the contrary...

o   In section 3 it reads "the protocol builds on rfc6415", which is very unclear to which extent

o   Section 5 talks about backward-compatibility but basically says it "may not be". This is mainly to reuse jrd and "host-meta.json" so it may be more appropriate to call them out explicitly without any generic sentence (still if this is the feeling of the group)

o   Section 5.1 references section 4.2 of rfc6415 but actually introduces some variants, so why not write a clean standalone text with no reference to rfc6415?

o   Section 5.2 references an "example" of rfc6415 section 1.1.1, but the value of that reference is not clear. Better probably to reference webfinger's own examples.

-          the very latest draft is still al "ALT" at this stage...

I'm playing the devil's advocate here but do think that the various camps intend very diverse usages of webfinger that maybe do not benefit of one solution. It is a pity those use cases are not reflected in the simplistic examples: I personally liked the openid one as I think opened connect would be 1 candidate, but I've heard about autoconfiguration (see oauth use case) and federated social networks (the whole original point of it). All of them are used in very different contexts (trusted/untrusted, intra-/inter-domain) and will probably distinguish themselves from the actual link rels they will use/expose...

walter

Da: [email-masked] [mailto:[email-masked]] Per conto di Evan Prodromou
Inviato: venerdì 2 novembre 2012 16.05
A: [email-masked]
Oggetto: Re: [apps-discuss] High-level considerations about "webfinger"

The conversation has really moved on! I suggest you read Paul Jones's latest email to get caught up.

-Evan

Cheers
walter

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.
Rispetta l'ambiente. Non stampare questa mail se non è necessario.

[email-masked]<mailto:[email-masked]>

Rispetta l'ambiente. Non stampare questa mail se non è necessario.

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 3 Nov 2012 02:50:48 -0400

Walter, et al,

(Apologizes for the length, but I think we have an important directional
decision to make…)

I think down below you summarized the situation pretty well.  While
generalizing, what I think we have are two different camps.  There are those
who have a preference for RFC 6415 as it’s defined today.  There are a list
of people who said they like the host-meta approach with host-specific and
then separate resource-specific information and the use of templates
(notably the one for LRDD).  Then there is the group who does not.  They
just want to issue a single query and get back a single response.  The
latter group do not like templates and do not want to make two requests.
Oh, and they do not care one way or the other about preserving
backward-compatibility with RFC 6415.  (Now, my statements about the two
camps is a generalization, a I said at the outset, and there are opinions
that cross boundaries, but this is the cleanest division I can see for the
purposes of discussion.)

What I’ve tried to do is define a solution that would allow for a single
request/response, but would maintain a high-degree of interoperability
between this new document and 6415.  As I was making changes to the draft
and trying to take input, I was trying to think through how I could produce
a solution to meet the requirements without a host-meta server modified in
any way, except for the addition of “resource” and JRD support.  Ignoring
the editorial improvements that could be made, I think the current ALT-R1
draft does that.

You are entirely correct that this spec is looking more like SWD.  There are
some very important distinctions, though.  For one, SWD returns a single
link to a single request.  It makes discovering lots of information about
somebody a pain, IMO.  It’s primary purpose was to support OpenID Connect
and it works fine for that, but if I want to ask a sever to “tell me
everything you know about Paul Jones”, it cannot.  RFC 6415 can, and I like
that.  The difference is really a matter of the document returned.  Also,
there is application-level kind of redirect in SWD (or was) that really
should be an HTTP-level (3xx).  I don’t like that about SWD, either.

Back to the two camps: neither is happy with the present solution (the -02
draft).  People who like the single request approach like this ALT drafts
better because XML is gone, there is a single resource to go query, and, of
course, there is a single request/response.  People who are in the 6415 camp
do are not happy with the -02 draft because we turn “host metadata” into
“resource” information: we merge the concepts.  They also do not like the
ALT drafts for the same reason.  However, even the 6415 camp does seem to
have an appreciation for a resource-centric approach that can use a single
query.  They just don’t like the “hack” (my term… that’s the one negative
word I don’t think I’ve had thrown in my face ;-) ).

I believe you are right to point out that the one thing people seem to be
generally OK with is JRD.  I think it’s a simple format, nice to work with,
useful, and not overly complicated.  Given that there are virtually no
comments on the format, I gather people share the same sentiment.

Now, having had conversations with a number of people both on the list and
off, I believe we need to decide which direction to take and I think there
are two choices:

1)      We discard the current WebFinger draft and continue with RFC 6415
as-is

2)      We re-write the spec in the spirit of the ALT versions, completely
breaking away from RFC 6415 by

a.       Removing all references to and dependencies on RFC 6415

b.      Defining JRD within the WebFinger spec, specifying such things as
“the order of link relations is significant” or other rules we want to apply
to the document

c.       Defining a new resource for this server at /.well-known/webfinger
(or swd ?)

d.      Using no templates whatsoever

e.      Using the “resource” parameter as the current ALT draft has them
(the concept of “host metadata” does not exist with this draft; I’m not sure
what the server should do if the resource parameter is absent, though)

f.        (I would say use the “rel” parameter, too, but some have really
expressed dissatisfaction with that.  While I think it’s wonderful in order
to reduce the number of link relations returned, some just saw no value in
that… even on narrow-band network connections.)

If I understand the two camps, I think those are the two options before us.
I’m sure there may be other things to do for option 2, but you get the gist
of where that is headed.

More importantly, I am left with the impression that if we do go with option
2, we will get support from both camps.  Some of those who are in the 6415
camp just have an objective of not breaking what is there now and some just
don’t want the “hack” that is the current WF spec.  But, I believe most are
all for a clean specification that defines a useful service and that
utilizes JRD to provide a set of link relations about a resource; a useful
“web discovery protocol”.

I just want a solution and would not be upset with either solution.  What I
do not like, though, is having two or three solutions for discovery.  At
present, we have RFC 6415, current WF draft, SWD, and
draft-daboo-agreggated-service-discovery.  That’s a few too many ;-)

I do have a high opinion of XRD/JRD, so I would like to see either or both
of those retained in any solution the group produces.

Given that SWD exists, I take it that there is at least enough support to do
something other than RFC 6415. I do not fully understand the reasons, except
perhaps “we want one round trip”. I don’t know.  Perhaps someone can educate
me on the “why”.  But, it does exist, so there is a reason and it means we
might end up with two solutions.

So, can we avoid that?  I’d be ok with putting aside the WF spec in favor a
merger between SWD/WF.  I don’t want to call this a “compromise”, but rather
a clean solution that borrows from both: single round trip (like SWD), a
richer response with a set of links (JRD), adheres to and follows HTTP
procedures (e.g., no “SWD_service_redirect” type construct; use 3xx), has no
templates in the JRD, allows any URI type (including “acct:”) as the
“subject” of the query, and is rooted at the host at some agreed location
like /.well-known/swd.

I believe if we do this, we have the greatest chance of getting the largest
number of people on board.  Perhaps Mike or someone serve as editing, but
I’d be happy to help co-author.  I’ll also write an implementation as I did
for RFC 6415; it should be simple to do.

In any case, I do think there is a serious risk of failure if we continue
down the current WF path, either because we end up with multiple competing
solutions or because we alienate one of the two camps.  So we either stick
with 6415 and stop spending time on this, or create something along the
lines of (2) where we can get nearly everyone on board.

Paul

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Goix Laurent Walter
Sent: Friday, November 02, 2012 11:30 AM
To: Evan Prodromou; [email-masked]
Subject: [apps-discuss] R: High-level considerations about "webfinger"

Hi evan,

I do have read the latest alt-r1 draft. But I do believe these are still
applicable questions:

-          I could still see pros/cons in the list for rel/resource
parameters in host-meta.json

-          The question of creating a new endpoint has been raised and still
pending imo (also wrt previous bullet)

-          Relationship with rfc6415 is still not clear as some parts are
clearly referenced (mostly procedures) whilst others mention a clear
distance with it (eg xrd vs jrd). As a developer I could not know very well
whether I need to implement rfc6415 and how much of it…at this point one may
consider how much the draft gains in actually referencing those sections if
it is to mandate the contrary…

o   In section 3 it reads “the protocol builds on rfc6415”, which is very
unclear to which extent

o   Section 5 talks about backward-compatibility but basically says it “may
not be”. This is mainly to reuse jrd and “host-meta.json” so it may be more
appropriate to call them out explicitly without any generic sentence (still
if this is the feeling of the group)

o   Section 5.1 references section 4.2 of rfc6415 but actually introduces
some variants, so why not write a clean standalone text with no reference to
rfc6415?

o   Section 5.2 references an “example” of rfc6415 section 1.1.1, but the
value of that reference is not clear. Better probably to reference
webfinger’s own examples.

-          the very latest draft is still al “ALT” at this stage…

I’m playing the devil’s advocate here but do think that the various camps
intend very diverse usages of webfinger that maybe do not benefit of one
solution. It is a pity those use cases are not reflected in the simplistic
examples: I personally liked the openid one as I think opened connect would
be 1 candidate, but I’ve heard about autoconfiguration (see oauth use case)
and federated social networks (the whole original point of it). All of them
are used in very different contexts (trusted/untrusted, intra-/inter-domain)
and will probably distinguish themselves from the actual link rels they will
use/expose…

walter

Da: [email-masked] [mailto:[email-masked]] Per
conto di Evan Prodromou
Inviato: venerdì 2 novembre 2012 16.05
A: [email-masked]
Oggetto: Re: [apps-discuss] High-level considerations about "webfinger"

The conversation has really moved on! I suggest you read Paul Jones's latest
email to get caught up.

-Evan

Dear all,

I tried to catch up with the hot discussion of the last days and would try
to hold on for the time of an email trying to summarize the current
situation and take a breath…

At this stage we are having very distinct camps in the list for what they
have in mind behind the “webfinger” keyword: xml vs json, 1 or 2 roundtrips,
privacy ecc. It seems to me that Paul has been doing an outstanding work
trying to compromise (I would have lost patience…) but such compromises do
not seem to satisfy anyone: actually, compromises are moving more and more
towards the original SWD idea at the end.

-          With the “xrd” idea in mind (please, jrd-enthusiasts, try to put
that hat on as well), what is actually missing beyond rfc6415 for
“webfinger”? now the ‘acct’ URI is a separate draft (an initial motivation).
Rel/resource parameters for xrd supporters do not seem essential in my
understanding neither. So (although I am a supports of that camp) I have
trouble seeing what truly need to be added. I can understand Evan’s position
for keeping the entire xrd-based community (ostatus, diaspora, etc) but
isn’t rfc6415-compliance for those existing implementations already fair
enough? If a new “webfinger” is jrd, 1-roundtrip only at the end it’s just
another rfc number to be referenced instead/in addition and as such has the
same value…(not mentioning the implementation work needed)

-          Rfc6415-compliance & backward compatibility: this seems also
contentious as whether backward-compatibility is needed or not. however the
current “compromises” are odd in maintaining backward-compability. What is
exactly interesting for “webfinger” from that rfc? From the latest
alternative it seems only the “host-meta.json” endpoint name & the jrd. Or
else? How these can be referenced at best without needing the whole thing? 

-          Host-meta+lrdd vs new endpoint: Should we propose an alternative
endpoint name (there were many proposals, including one of mine a while ago)
so that we simply “distinguish” the existing host-meta+lrdd way from a new
“webfinger” way/endpoint all-in-1-roundtrip. This is what swd is proposing.
Eventually one could at the end use the same backend implementation to
return queries coming all the way from host-meta+lrdd than others using
another well-known (and direct) endpoint. This would also be much easier to
support any query parameter (resource, rel, etc) as some are arguing against
overriding host-meta with parameters. In that case the new “webfinger” would
be actually more like SWD (with JRD support)

-          In alternative, what about the provocative idea from Evan to
“replace” rfc6415? Are they other usages of rfc6415 than the “webfinger” one
throughout the community? If yes, then it may be more difficult to replace
unless agreed with whom is using it. Otherwise, as it seems most people do
not like it, why keep it as-is and not upgrade directly to whatever is now
useful? A standard that is not used is useless and has no point in being
superseded by a parallel spec not actually obsoleting it... If JRD and the
well-known endpoints are useful in other context, then why not splitting
them from the actual protocol procedures of current rfc6415 and have clean
specs that can be generically referenced without buying the full thing or
writing complex text to select some parts of it and contest others: 1 for
JRD and 1 for the endpoints/link registrations. Then a protocol-oriented
spec like webfinger can easily decide what to take and replace current
rfc6415, or decide to live separately/parallel.

Personally I have more interest and feeling for the 2-roundtrip xrd solution
from rfc6415 still. But if I have to choose between an
odd/partial/unstable/unclear/buggy reference to it and a new json way for
satisfying another use case I have to put limits in compromising and at this
point prefer a parallel/independent approach. Of course I’d like possibly to
reuse the file format (jrd) as it seems suitable for all. At least this way
rfc6415 can still live independently (being updated or not if we want to
make it “cleaner”) and “webfinger” can hopefully be finalized quickly in the
json + 1 roundtrip direction…

Once these macro topics are clarified then we can better discuss the details
about securing wf, supporting privacy, distinct delivery for auth/non-auth
requests etc…But can we first discuss at high level what we want to achieve
in terms of process?

Cheers

walter

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. 

rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se non è
necessario. 

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. 

rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se non è
necessario.

---

From: Mike Jones <[email-masked]>
Date: Sat, 3 Nov 2012 07:47:30 +0000

Good analysis. +1 to creating something along the lines of (2).

-- Mike

________________________________
From: Paul E. Jones
Sent: 11/3/2012 7:50 AM
To: 'Goix Laurent Walter'; 'Evan Prodromou'; [email-masked]
Cc: [email-masked]; Mike Jones
Subject: RE: [apps-discuss] R:  High-level considerations about "webfinger"

Walter, et al,

(Apologizes for the length, but I think we have an important directional decision to make…)

I think down below you summarized the situation pretty well.  While generalizing, what I think we have are two different camps.  There are those who have a preference for RFC 6415 as it’s defined today.  There are a list of people who said they like the host-meta approach with host-specific and then separate resource-specific information and the use of templates (notably the one for LRDD).  Then there is the group who does not.  They just want to issue a single query and get back a single response.  The latter group do not like templates and do not want to make two requests.  Oh, and they do not care one way or the other about preserving backward-compatibility with RFC 6415.  (Now, my statements about the two camps is a generalization, a I said at the outset, and there are opinions that cross boundaries, but this is the cleanest division I can see for the purposes of discussion.)

What I’ve tried to do is define a solution that would allow for a single request/response, but would maintain a high-degree of interoperability between this new document and 6415.  As I was making changes to the draft and trying to take input, I was trying to think through how I could produce a solution to meet the requirements without a host-meta server modified in any way, except for the addition of “resource” and JRD support.  Ignoring the editorial improvements that could be made, I think the current ALT-R1 draft does that.

You are entirely correct that this spec is looking more like SWD.  There are some very important distinctions, though.  For one, SWD returns a single link to a single request.  It makes discovering lots of information about somebody a pain, IMO.  It’s primary purpose was to support OpenID Connect and it works fine for that, but if I want to ask a sever to “tell me everything you know about Paul Jones”, it cannot.  RFC 6415 can, and I like that.  The difference is really a matter of the document returned.  Also, there is application-level kind of redirect in SWD (or was) that really should be an HTTP-level (3xx).  I don’t like that about SWD, either.

Back to the two camps: neither is happy with the present solution (the -02 draft).  People who like the single request approach like this ALT drafts better because XML is gone, there is a single resource to go query, and, of course, there is a single request/response.  People who are in the 6415 camp do are not happy with the -02 draft because we turn “host metadata” into “resource” information: we merge the concepts.  They also do not like the ALT drafts for the same reason.  However, even the 6415 camp does seem to have an appreciation for a resource-centric approach that can use a single query.  They just don’t like the “hack” (my term… that’s the one negative word I don’t think I’ve had thrown in my face ;-) ).

I believe you are right to point out that the one thing people seem to be generally OK with is JRD.  I think it’s a simple format, nice to work with, useful, and not overly complicated.  Given that there are virtually no comments on the format, I gather people share the same sentiment.

Now, having had conversations with a number of people both on the list and off, I believe we need to decide which direction to take and I think there are two choices:

1)      We discard the current WebFinger draft and continue with RFC 6415 as-is

2)      We re-write the spec in the spirit of the ALT versions, completely breaking away from RFC 6415 by

b.      Defining JRD within the WebFinger spec, specifying such things as “the order of link relations is significant” or other rules we want to apply to the document

c.       Defining a new resource for this server at /.well-known/webfinger (or swd ?)

e.      Using the “resource” parameter as the current ALT draft has them (the concept of “host metadata” does not exist with this draft; I’m not sure what the server should do if the resource parameter is absent, though)

f.        (I would say use the “rel” parameter, too, but some have really expressed dissatisfaction with that.  While I think it’s wonderful in order to reduce the number of link relations returned, some just saw no value in that… even on narrow-band network connections.)

If I understand the two camps, I think those are the two options before us.  I’m sure there may be other things to do for option 2, but you get the gist of where that is headed.

More importantly, I am left with the impression that if we do go with option 2, we will get support from both camps.  Some of those who are in the 6415 camp just have an objective of not breaking what is there now and some just don’t want the “hack” that is the current WF spec.  But, I believe most are all for a clean specification that defines a useful service and that utilizes JRD to provide a set of link relations about a resource; a useful “web discovery protocol”.

I just want a solution and would not be upset with either solution.  What I do not like, though, is having two or three solutions for discovery.  At present, we have RFC 6415, current WF draft, SWD, and  draft-daboo-agreggated-service-discovery.  That’s a few too many ;-)

I do have a high opinion of XRD/JRD, so I would like to see either or both of those retained in any solution the group produces.

Given that SWD exists, I take it that there is at least enough support to do something other than RFC 6415. I do not fully understand the reasons, except perhaps “we want one round trip”. I don’t know.  Perhaps someone can educate me on the “why”.  But, it does exist, so there is a reason and it means we might end up with two solutions.

So, can we avoid that?  I’d be ok with putting aside the WF spec in favor a merger between SWD/WF.  I don’t want to call this a “compromise”, but rather a clean solution that borrows from both: single round trip (like SWD), a richer response with a set of links (JRD), adheres to and follows HTTP procedures (e.g., no “SWD_service_redirect” type construct; use 3xx), has no templates in the JRD, allows any URI type (including “acct:”) as the “subject” of the query, and is rooted at the host at some agreed location like /.well-known/swd.

I believe if we do this, we have the greatest chance of getting the largest number of people on board.  Perhaps Mike or someone serve as editing, but I’d be happy to help co-author.  I’ll also write an implementation as I did for RFC 6415; it should be simple to do.

In any case, I do think there is a serious risk of failure if we continue down the current WF path, either because we end up with multiple competing solutions or because we alienate one of the two camps.  So we either stick with 6415 and stop spending time on this, or create something along the lines of (2) where we can get nearly everyone on board.

Paul

From: [email-masked] [mailto:[email-masked]] On Behalf Of Goix Laurent Walter
Sent: Friday, November 02, 2012 11:30 AM
To: Evan Prodromou; [email-masked]
Subject: [apps-discuss] R: High-level considerations about "webfinger"

Hi evan,

-          Relationship with rfc6415 is still not clear as some parts are clearly referenced (mostly procedures) whilst others mention a clear distance with it (eg xrd vs jrd). As a developer I could not know very well whether I need to implement rfc6415 and how much of it…at this point one may consider how much the draft gains in actually referencing those sections if it is to mandate the contrary…

o   In section 3 it reads “the protocol builds on rfc6415”, which is very unclear to which extent

o   Section 5 talks about backward-compatibility but basically says it “may not be”. This is mainly to reuse jrd and “host-meta.json” so it may be more appropriate to call them out explicitly without any generic sentence (still if this is the feeling of the group)

o   Section 5.2 references an “example” of rfc6415 section 1.1.1, but the value of that reference is not clear. Better probably to reference webfinger’s own examples.

I’m playing the devil’s advocate here but do think that the various camps intend very diverse usages of webfinger that maybe do not benefit of one solution. It is a pity those use cases are not reflected in the simplistic examples: I personally liked the openid one as I think opened connect would be 1 candidate, but I’ve heard about autoconfiguration (see oauth use case) and federated social networks (the whole original point of it). All of them are used in very different contexts (trusted/untrusted, intra-/inter-domain) and will probably distinguish themselves from the actual link rels they will use/expose…

walter

Da: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] Per conto di Evan Prodromou
Inviato: venerdì 2 novembre 2012 16.05
A: [email-masked]<mailto:[email-masked]>
Oggetto: Re: [apps-discuss] High-level considerations about "webfinger"

-Evan

I tried to catch up with the hot discussion of the last days and would try to hold on for the time of an email trying to summarize the current situation and take a breath…

At this stage we are having very distinct camps in the list for what they have in mind behind the “webfinger” keyword: xml vs json, 1 or 2 roundtrips, privacy ecc. It seems to me that Paul has been doing an outstanding work trying to compromise (I would have lost patience…) but such compromises do not seem to satisfy anyone: actually, compromises are moving more and more towards the original SWD idea at the end.

-          With the “xrd” idea in mind (please, jrd-enthusiasts, try to put that hat on as well), what is actually missing beyond rfc6415 for “webfinger”? now the ‘acct’ URI is a separate draft (an initial motivation). Rel/resource parameters for xrd supporters do not seem essential in my understanding neither. So (although I am a supports of that camp) I have trouble seeing what truly need to be added. I can understand Evan’s position for keeping the entire xrd-based community (ostatus, diaspora, etc) but isn’t rfc6415-compliance for those existing implementations already fair enough? If a new “webfinger” is jrd, 1-roundtrip only at the end it’s just another rfc number to be referenced instead/in addition and as such has the same value…(not mentioning the implementation work needed)

-          Rfc6415-compliance & backward compatibility: this seems also contentious as whether backward-compatibility is needed or not. however the current “compromises” are odd in maintaining backward-compability. What is exactly interesting for “webfinger” from that rfc? From the latest alternative it seems only the “host-meta.json” endpoint name & the jrd. Or else? How these can be referenced at best without needing the whole thing?

-          Host-meta+lrdd vs new endpoint: Should we propose an alternative endpoint name (there were many proposals, including one of mine a while ago) so that we simply “distinguish” the existing host-meta+lrdd way from a new “webfinger” way/endpoint all-in-1-roundtrip. This is what swd is proposing. Eventually one could at the end use the same backend implementation to return queries coming all the way from host-meta+lrdd than others using another well-known (and direct) endpoint. This would also be much easier to support any query parameter (resource, rel, etc) as some are arguing against overriding host-meta with parameters. In that case the new “webfinger” would be actually more like SWD (with JRD support)

-          In alternative, what about the provocative idea from Evan to “replace” rfc6415? Are they other usages of rfc6415 than the “webfinger” one throughout the community? If yes, then it may be more difficult to replace unless agreed with whom is using it. Otherwise, as it seems most people do not like it, why keep it as-is and not upgrade directly to whatever is now useful? A standard that is not used is useless and has no point in being superseded by a parallel spec not actually obsoleting it... If JRD and the well-known endpoints are useful in other context, then why not splitting them from the actual protocol procedures of current rfc6415 and have clean specs that can be generically referenced without buying the full thing or writing complex text to select some parts of it and contest others: 1 for JRD and 1 for the endpoints/link registrations. Then a protocol-oriented spec like webfinger can easily decide what to take and replace current rfc6415, or decide to live separately/parallel.

Personally I have more interest and feeling for the 2-roundtrip xrd solution from rfc6415 still. But if I have to choose between an odd/partial/unstable/unclear/buggy reference to it and a new json way for satisfying another use case I have to put limits in compromising and at this point prefer a parallel/independent approach. Of course I’d like possibly to reuse the file format (jrd) as it seems suitable for all. At least this way rfc6415 can still live independently (being updated or not if we want to make it “cleaner”) and “webfinger” can hopefully be finalized quickly in the json + 1 roundtrip direction…

Once these macro topics are clarified then we can better discuss the details about securing wf, supporting privacy, distinct delivery for auth/non-auth requests etc…But can we first discuss at high level what we want to achieve in terms of process?

Cheers
walter

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.
[rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa mail se non è necessario.

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.
[rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa mail se non è necessario.

---

From: Brad Fitzpatrick <[email-masked]>
Date: Sat, 3 Nov 2012 12:48:51 +0100

I'm not against a single round-trip, but I am against abusing host-meta
with query params.

I have no problems with JRD as a response format.

I'm in support of dropping webfinger's dependency on RFC 6415, using
/.well-known/webfinger instead (and thus not abusing host-meta), and
keeping with one round trip.

If you want to query a host, use /.well-known/host-meta{,.json}.
If you want to query a user@host, use
/.well-known/webfinger?rel=...&resource=....

Both are one round-trip, CORS, etc.

(Background: years ago I was advocating two round-trips, one for host
discovery and then one for making the webfinger query, because I was
worried about global load balancing and large organization politics of who
owns what parts of the HTTP namespace, but I'm much less worried about that
these days.  It's not a problem for small orgs and individuals, and it's
not a problem for Google, so I'm fine accepting that it's not actually a
problem worth worrying about.)

So count me in for +1 on single round-trip and /.well-known/webfinger and
even dropping templates.

Christian makes a good point that host-meta upgrades well to discovering
the /.well-known/webfinger endpoint for legacy clients.

- Brad

On Sat, Nov 3, 2012 at 10:36 AM, Christian Weiske <[email-masked]>wrote:

> Hello Paul,
> I was for long in the RFC 6415 camp, and I still am. Reusing existing
> standards makes much sense in my eyes.
>
> Given that people like the one request approach (I do see its
> benefits, too), and that adding a resource parameter to host-meta is a
> dirty hack, I'd rather go with a new resource - /.well-known/webfinger.
>
> This separates it cleanly, allows the one request solution without
> hacks, and is even backward compatible with existing clients if the
> lrdd link is changed to /.well-known/webfinger?resource={uri}.
> Not that it is that important, but it's nice to have.
>
>
> --
> Regards/Mit freundlichen Grüßen
> Christian Weiske
>
> -=≡ Geeking around in the name of science since 1982 ≡=-
>

---

From: Christian Weiske <[email-masked]>
Date: Sat, 3 Nov 2012 10:36:08 +0100

Hello Paul,

---

From: Goix Laurent Walter <[email-masked]>
Date: Sat, 3 Nov 2012 16:21:55 +0100

Thanks Paul! It reminds me of an early discussion we had on this about document-oriented vs API approach. Option 2, probably the best way forward, is a sort of API...we can define parameters etc.
If the group sticks with Jrd and the other considerations you made on http redirects etc I do guess this is a clean API (one could even think of POST/PUT/DELETE for this :) ). And it leaves 6415 unchanged and working. Some could say useless if wf/swd merger is created, but actually this way we build something parallel/independent indeed, so 6415 has still its dignity and is not broken into good and bad parts...

Personally, for my own view of federated social networks and my OMA hat on,  I do would sponsor an 6415-based solution across social network providers for peering and cross-discovery.
But I do see value in a new json-based API/endpoint for other use cases and am willing to help. Note that this could actually be view as standardizing the 'Lrdd' endpoint :) (although json-only) so I still see it somehow compatible with the existing 6415 framework...if we name the endpoint .well-known/lrdd we even avoid the wf/swd name battle ;)

Moving on towards option 2, I do have still the following concerns:
- would the whole activity anyway benefit from slightly updating 6415 in parallel of the wf activity eg to call jrd out of a simple appendix for a cleaner reference (potentially also by other specs in the future), and maybe with other things as well such as cors or else? What is the view of the authors of 6415?

- I still see that the most relevant use cases discussed over the last months are actually missing from the text. Fsn, openid connect, auto configuration & 'contact enrichment' are 4 main use cases with very different needs that would deserve being mentioned explicitly.

As a side comment, I may be too optimistic/quick but I'd also like to work with whoever is interested at analyzing link rels relevant for the fsn use case in particular and possibly have some of them registered if missing to pave the way for interoperability.

Walter

Le 3 nov. 2012 à 07:50, "Paul E. Jones" <[email-masked]<mailto:[email-masked]>> a écrit :

Walter, et al,

Paul

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Goix Laurent Walter
Sent: Friday, November 02, 2012 11:30 AM
To: Evan Prodromou; [email-masked]<mailto:[email-masked]>
Subject: [apps-discuss] R: High-level considerations about "webfinger"

Hi evan,

walter

-Evan

Cheers
walter

---

From: Goix Laurent Walter <[email-masked]>
Date: Sat, 3 Nov 2012 16:25:22 +0100

I was writing my answer when you sent yours...clearly we got aligned on the seamless integration of the lrdd link :)

Le 3 nov. 2012 à 16:06, "Christian Weiske" <[email-masked]> a écrit :

> <signature.asc>

---

From: Blaine Cook <[email-masked]>
Date: Sat, 3 Nov 2012 18:48:23 +0000

+1 to all this. Hooray!

A few thoughts on unifying the thinking based on the excellent
contributions so far:

– Use host-meta as a fallback for when /.well-known/webfinger isn't present.
– A big +1 to only using HTTP redirects.
– Drop the template requirement for rel='webfinger' links; the semantics
are described by webfinger itself, so only the URL is required (i.e.,
deprecate LRDD in that respect).

The only other comment I have at the moment is that I still really oppose
the allowance of 301 (Permanent) redirects in webfinger. I can't imagine a
scenario where that makes sense, and I can imagine all sorts of scenarios
where it could be actively harmful.

b.

On 3 November 2012 15:25, Goix Laurent Walter <
[email-masked]<https://mail.google.com/mail/?view=cm&fs=1&tf=1&to=[email-masked]>
> wrote:

> I was writing my answer when you sent yours...clearly we got aligned on
> the seamless integration of the lrdd link :)
>
> Le 3 nov. 2012 à 16:06, "Christian Weiske" <[email-masked]<https://mail.google.com/mail/?view=cm&fs=1&tf=1&to=[email-masked]>>
> a écrit :
>
> > Hello Paul,
> >
> >
> > [email-masked]<https://mail.google.com/mail/?view=cm&fs=1&tf=1&to=[email-masked]>
> 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.
>
> [email-masked]<https://mail.google.com/mail/?view=cm&fs=1&tf=1&to=[email-masked]>

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 3 Nov 2012 19:37:33 -0400

Walter,

We could update RFC 6415, but we should keep that as a separate activity. That said, is there truly a benefit?  No opposition, but I’m not sure if there is a lot of value in doing so.

The relevance of the examples was a question with the current WebFinger draft, too.  It would be useful to have real-world examples, I agree.  That said, they should be simple ones so as to not loose effect.

Paul

From: Goix Laurent Walter [mailto:[email-masked]] 
Sent: Saturday, November 03, 2012 11:22 AM
To: Paul E. Jones
Cc: Evan Prodromou; [email-masked]; [email-masked]; Mike Jones
Subject: Re: [apps-discuss] R: High-level considerations about "webfinger"

Walter

Le 3 nov. 2012 à 07:50, "Paul E. Jones" <[email-masked]> a écrit :

Walter, et al,

Paul

Hi evan,

walter

-Evan

Dear all,

 

Cheers

walter

---

From: Evan Prodromou <[email-masked]>
Date: Sun, 04 Nov 2012 16:29:15 -0500

+1,000,000.

I think this is a great way to do it.

-Evan

---

From: Goix Laurent Walter <[email-masked]>
Date: Mon, 5 Nov 2012 11:57:58 +0100

Hello Paul,
Comments as [walter]

Da: Paul E. Jones [mailto:[email-masked]]
Inviato: domenica 4 novembre 2012 0.38
A: Goix Laurent Walter
Cc: 'Evan Prodromou'; [email-masked]; [email-masked]; 'Mike Jones'
Oggetto: RE: [apps-discuss] R: High-level considerations about "webfinger"

Walter,

[walter] it is truly mainly aimed at “elevating” JRD to a standalone spec to be more easily referenceable than being nested as a simple appendix in another independent spec. Plus potential minor updates if needed. But no big issue.

[walter] agreed. I can try to provide one for federated social networks for the next revision if you/group wish.

Paul

Walter

Paul

Hi evan,

walter

-Evan

Cheers
walter

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 05 Nov 2012 10:53:52 -0500

So you want a JRD RFC, not just a JRD section in WF? If so, we need someone to author that immediately.

 Paul

-------- Original Message --------
From: Goix Laurent Walter <[email-masked]>
Sent: Mon Nov 05 05:57:58 EST 2012
To: "Paul E. Jones" <[email-masked]>
Cc: 'Evan Prodromou' <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, 'Mike Jones' <[email-masked]>
Subject: R: [apps-discuss] R:  High-level considerations about "webfinger"

Hello Paul,
Comments as [walter]

Walter,

Paul

Walter

Paul

Hi evan,

walter

-Evan

-          In alternative, what about the provocative idea from Evan to “replace” rfc6415? Are they other usages of rfc6415 than the “webfinger” one throughout the community? If yes, then it may be more difficult to replace unless agreed with whom is using it. Otherwise, as it seems most people do not like it, why keep it as-is and not upgrade directly to whatever is now useful? A standard that is not used is useless and has no point in being superseded by a parallel spec not actually obsoleting it... If JRD and the well-known endpoints are useful in other context, then why not splitting them from the actual protocol procedures of current rfc6415 and have clean specs that can be generically referenced without buying the full thing or writing complex text to select some parts of it and contest others: 1 for JRD and 1 for the endpoints/link registrations. Then a protocol-oriented spec like webfinger can easily decide what to take and replace current rfc6415, or decide !
 to live
separately/parallel.

Cheers
walter

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 05 Nov 2012 14:23:56 -0500

That offers a third option. We have:
* New draft for JRD
* Reference to RFC 6415
* inclusion of JRD description in new WF draft

I thought folks wanted the latter, even if redundant. I have no preference, but I thought folks wanted to have no references to the host-meta do.

Paul

-------- Original Message --------
From: Christian Weiske <[email-masked]>
Sent: Mon Nov 05 13:21:52 EST 2012
To: [email-masked]
Cc: "[email-masked]" <[email-masked]>
Subject: Re: R: [apps-discuss] R:  High-level considerations about "webfinger"

Hello Paul,

> someone to author that immediately.

I'm totally fine with JRD being defined as it is currently, in RFC
6415, Appendix A. 

I see no value in having it in an independent RFC. The goal cannot (and
must not) be to have a totally self-contained RFC that is only two
sentences long. It's very fine to built up on others.

---

From: Brad Fitzpatrick <[email-masked]>
Date: Mon, 5 Nov 2012 20:28:03 +0100

I'm fine with a reference to small, well-defined parts of RFC 6415.
 Especially if it's the most expedient option.

I just don't want to override and insert into parts of RFC 6415 as the old
drafts seemed to.

But I'm fine with all three options, really.

On Mon, Nov 5, 2012 at 8:23 PM, Paul E. Jones <[email-masked]> wrote:

> I thought folks wanted the latter, even if redundant. I have no
> preference, but I thought folks wanted to have no references to the
> host-meta do.
>
> *Paul*
>
>
> ------------------------------
> *From:* Christian Weiske <[email-masked]>
> *Sent:* Mon Nov 05 13:21:52 EST 2012
> *To:* [email-masked]
> *Cc:* "[email-masked]" <[email-masked]>
> *Subject:* Re: R: [apps-discuss] R: High-level considerations about
> "webfinger"
>
> Hello Paul,
>
>

---

From: Brad Fitzpatrick <[email-masked]>
Date: Mon, 5 Nov 2012 21:56:37 +0100

On Mon, Nov 5, 2012 at 9:04 PM, Dick Hardt <[email-masked]> wrote:

> I just read RFC 6415 Appendix A
> http://tools.ietf.org/html/rfc6415#appendix-A
>
> A JRD is defined in context of an XRD. To understand the Appendix, one
> must understand XRD.
>
[...]

> It is like defining JSON in terms of XML. Yuck.
>

I agree that it's twisty and not ideal, but on the other hand, it provides
a JSON example which is pretty much sufficient on its own.

I'm ambivalent here, torn between pedantry and impatience.

+0

---

From: Christian Weiske <[email-masked]>
Date: Mon, 5 Nov 2012 19:21:52 +0100

Hello Paul,

---

From: Dick Hardt <[email-masked]>
Date: Mon, 5 Nov 2012 12:04:46 -0800

I just read RFC 6415 Appendix A http://tools.ietf.org/html/rfc6415#appendix-A

A JRD is defined in context of an XRD. To understand the Appendix, one must understand XRD. 

Let's take for example the "expires" property. The Appendix says it is a string.  

To figure out the format of the string, one must dig through RFC 6415 to realize that it does not define XRD,  you must go to the OASIS spec, specifically: http://docs.oasis-open.org/xri/xrd/v1.0/xrd-1.0.html#element.expires

When you go there, it is not clear what the format should be. The example does not have a time string in it. There is a reference to it being in URC form.

IMHO: the JRD reference was an attempt to appease those that wanted JSON instead of XML. Referencing RFC 6415 may be the easy path, but it puts a large burden on implementors in trying to figure out the document format. It is like defining JSON in terms of XML. Yuck.

-- Dick

---

From: Dick Hardt <[email-masked]>
Date: Mon, 5 Nov 2012 13:50:15 -0800

On Nov 5, 2012, at 12:56 PM, Brad Fitzpatrick <[email-masked]> wrote:

> I agree that it's twisty and not ideal, but on the other hand, it provides a JSON example which is pretty much sufficient on its own.
> 

How about we ensure we have broad example JRD coverage in the WebFinger specification and then reference RFC 6415 Appendix A?

With enough variety in examples in this spec, an implementor can figure out what to output and what to expect without having to parse several other specifications.

-- Dick

---

From: t.petch <[email-masked]>
Date: Thu, 15 Nov 2012 15:05:36 +0000

This list has provided a home for a number of considerations of 'IANA
Considerations' so I hope it may provide inspiration here.

RFC4379 set up a registry
http://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-p
arameters.xml
of TLVs (functions) and sub-TLVs (parameters)
with each TLV having its own namespace of sub-TLVs.  The registry has
expanded in both directions, with new TLVs being added and new sub-TLVs
being added to existing TLVs.  Last year,
draft-ietf-mpls-ipv6-pw-lsp-ping added, and changed, the sub-TLVs of TLV
Type 1, while draft-ietf-mpls-return-path-specified-lsp-ping added a new
TLV, Type 21, and for it, duplicated the existing sub-TLVs of
TLV Type 1, an early allocation of which is still visible in the IANA
Registry.  A later revision of this I-D switched to referencing the then
existing sub-TLVs of the Type 1 TLV.   This is an active area so more
changes are likely -
e.g. draft-zjns-mpls-lsp-ping-relay-reply may do so.

The question that seems not to have been noticed (until pointed out by a
lurker on the list), despite this being an active area, was whether or
not the ipv6-pw changes to the sub-TLVs of Type 1 should be carried
across
to Type 21 or not, and equally, whether reusing the Type 1 sub-TLVs for
Type 21 only applied to those then in existence, one of which ipv6-pw
was deprecating, or should also be applied to any future updates to the
sub-TLVs of Type 1.

The ipv6-pw I-D is currently in with the IESG with a DISCUSS suggesting
that the relevant part of the subject material belongs in a different
WG, which would make the chances of spotting such interactions yet more
remote:-(

With the benefit of hindsight, RFC4379 might have split the range of
sub-TLVs into a part common to all TLVs, and a part unique to a
particular TLV; but it didn't and it would be impractical to retrofit
that now.

How could the IANA considerations be modified to alert those amending
the
sub-TLVs of Type 1 TLV to the fact that they are used elsewhere, and to
alert those reusing the sub-TLVs of another Type of TLV to the fact that
a registry of sub-TLVs is volatile and could be added to or deprecated?
Since this (almost) did not happen a single list while this topic is
still
distinctly active, I expect that it will recur.  Or do I worry too much?

Tom Petch