Subject: [apps-discuss] WF flow with rel parameter

From: John Bradley <[email-masked]>
Date: Tue, 24 Apr 2012 23:16:35 -0300

Paul,

Sorry I hit send on the previous message with a typo.

I am looking at how the flows in WF might work for openID.

Let's set aside the XML issue for the moment and focus on the JSON flow.

Please correct anything I get wrong.

The openID Connect defines a relation of http://openid.net/specs/connect/issuer

WF allows for a JSON host-meta that takes two parameters, "resource" and "rel"

An example request and response (line-brakes for readability)

GET /.well-known/host-meta.json
     ?resource=[email-masked]
     &rel=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer HTTP/1.1
 Host: example.com

   HTTP/1.1 200 OK

   Access-Control-Allow-Origin: *
   Content-Type: application/json; charset=UTF-8

   {
     "subject" : "[email-masked]",
     "links" :
     [
       {
         "rel" : "http://openid.net/specs/connect/issuer",
         "href" : "https://server.example.com"
       }
     ]
   }

If the host can't support rewrite rules or scripts the exchange would look like:

GET /.well-known/host-meta.json
     ?resource=[email-masked]
     &rel=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer HTTP/1.1
 Host: example.com

HTTP/1.1 200 OK
   Access-Control-Allow-Origin: *
   Content-Type: application/json; charset=UTF-8
   {
     "expires" : "2012-03-13T20:56:11Z",
     "links" :
     [
       {
         "rel" : "lrdd",
         "type" : "application/json",
         "template" :
           "https://example.com/lrdd/?format=json&resource={uri}"
       }

GET /lrdd/
     ?format=json
     &resource=[email-masked]
 Host: example.com

HTTP/1.1 200 OK

   Access-Control-Allow-Origin: *
   Content-Type: application/json; charset=UTF-8

   {
     "subject" : "[email-masked]",
     "links" :
     [
       {
         "rel" : "http://openid.net/specs/connect/issuer",
         "href" : "https://server.example.com"
       },
       {
         "rel" : "http://webfinger.net/rel/avatar",
         "href" : "http://example.com/~joe/joe.jpg"
       }

     ]
   }

I can't find a template parameter for "rel".  The host-meta spec allows for extension but it is missing.

What if the server wants to support filtering on rel but can't support it in the root for some reason?

Is it possible to have a template like:
"https://example.com/lrdd/?format=json&resource={uri}&rel={rel}"

That simple addition may solve a number of problems for openID.

John B.

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 25 Apr 2012 01:25:27 -0400

John,

The "rel" parameter is something we still need to discuss, so not is as good
a time as any.

What "rel" does is act as a filter.  For the most part, the only purpose it
serves is to help reduce the number of link relations that might be sent
from the server.  So, if a user had 1,000 different link relations, this
might reduce the returned message to containing only 1.  However, if a user
has more than one link relation of the same type, all of them would match
and be returned.

When you say the host cannot support re-write rules, I assume you mean it
does not support the URI parameters on host-meta?  In that case, yes, the
parameters are ignored and you get just the host-meta document.

The only URI template defined in RFC 6415 is "{uri}" (see 3.1.1.1).  There
are no other URI template values defined.  (Note: this whole section exists
only because RFC  6570 did not yet exist, I think.

In any case, we could define a new URI template, but then we would be
putting an optimization in place for LRDD.  If host-meta is not going to
support the "rel" URI parameter, why would LRDD?  It would also mean that
the LRDD logic would have to be ready to receive a URI parameter that is not
replaced, since some clients would only change {uri} and leave {rel} there.
That would introduce more conditional logic in the server.  This would also
present issues with static sites.  (Of course, one might be able to use
Apache re-writing rules to get around that problem, but it certainly would
not work for "real" static sites.)

Personally,  I'd prefer to not add the "rel" parameter to LRDD, since I
think optimization using "rel" would always be done on host-meta.  That
said, I question the value of "rel" entirely.  Do you think it's useful to
have this filter at all?  Is there really a risk that a site might return
1,000 link relations that the client would have to step over?

Paul

From: John Bradley [mailto:[email-masked]] 
Sent: Tuesday, April 24, 2012 10:17 PM
To: Paul E. Jones
Cc: [email-masked]
Subject: WF flow with rel parameter

Paul,

The openID Connect defines a relation of
http://openid.net/specs/connect/issuer

WF allows for a JSON host-meta that takes two parameters, "resource" and
"rel"

 Host: example.com <http://example.com/> 

   HTTP/1.1 200 OK

   {

     "links" :

     [

       {

         "href" : "https://server.example.com <https://server.example.com/>
"

       }

     ]

   }

If the host can't support rewrite rules or scripts the exchange would look
like:

 Host: example.com <http://example.com/> 

HTTP/1.1 200 OK

   {

     "links" :

     [

       {

         "rel" : "lrdd",

         "template" :

           "https://example.com/lrdd/?format=json
<https://example.com/lrdd/?format=json&resource=%7buri%7d> &resource={uri}"

       }

GET /lrdd/

     ?format=json

 Host: example.com <http://example.com/> 

HTTP/1.1 200 OK

   {

     "links" :

     [

       {

         "href" : "https://server.example.com <https://server.example.com/>
"

       },

       {

       }

     ]

   }

I can't find a template parameter for "rel".  The host-meta spec allows for
extension but it is missing.

What if the server wants to support filtering on rel but can't support it in
the root for some reason?

"https://example.com/lrdd/?format=json
<https://example.com/lrdd/?format=json&resource=%7buri%7d&rel=%7brel%7d>
&resource={uri}&rel={rel}"

John B.

---

From: John Bradley <[email-masked]>
Date: Wed, 25 Apr 2012 10:16:33 -0300

Paul, 

"rel" as a filter is something WF has for host-meta.  It however doesn't seem to have that for user JRD in the case where host-meta is returned, and the template is used.

The "resource" and "rel" parameters are already an optimization for LRDD and not part of host-meta.
Adding LRDD specific parameters to host-meta/host-meta.json will probably raise some eyebrows in review, but I am OK with it.

I think there are use cases where size matters.  Where a host-meta or resource JRD may be large and it is more efficient not to send the whole thing to a mobile client.
It seems to be one of Mike Jones requirements.

Using RFC6570 for LRDD is a possibility for passing through the filter request for sites that support filtering on resource JRD.

What other proposals do you have.  I am guessing that filtering on resource JRD is not a totally new topic.

LRDD is the one really doing the optimization  in any event,  it may be done at the host-meta GET but it is a LRDD specific extension.
Having it in the template allows LRDD to filter at the resource JRD in cases where it is not possible to do it at the host-meta level, due to some no script or other restriction.

I agree that it should be filtered at the how-meta request but you and others say that is not always possible.

John B.

On 2012-04-25, at 2:25 AM, Paul E. Jones wrote:

> John,
>  
> The “rel” parameter is something we still need to discuss, so not is as good a time as any.
>  
> What “rel” does is act as a filter.  For the most part, the only purpose it serves is to help reduce the number of link relations that might be sent from the server.  So, if a user had 1,000 different link relations, this might reduce the returned message to containing only 1.  However, if a user has more than one link relation of the same type, all of them would match and be returned.
>  
> When you say the host cannot support re-write rules, I assume you mean it does not support the URI parameters on host-meta?  In that case, yes, the parameters are ignored and you get just the host-meta document.
>  
> The only URI template defined in RFC 6415 is “{uri}” (see 3.1.1.1).  There are no other URI template values defined.  (Note: this whole section exists only because RFC  6570 did not yet exist, I think.
>  
> In any case, we could define a new URI template, but then we would be putting an optimization in place for LRDD.  If host-meta is not going to support the “rel” URI parameter, why would LRDD?  It would also mean that the LRDD logic would have to be ready to receive a URI parameter that is not replaced, since some clients would only change {uri} and leave {rel} there.  That would introduce more conditional logic in the server.  This would also present issues with static sites.  (Of course, one might be able to use Apache re-writing rules to get around that problem, but it certainly would not work for “real” static sites.)
>  
> Personally,  I’d prefer to not add the “rel” parameter to LRDD, since I think optimization using “rel” would always be done on host-meta.  That said, I question the value of “rel” entirely.  Do you think it’s useful to have this filter at all?  Is there really a risk that a site might return 1,000 link relations that the client would have to step over?
>  
> Paul
>

---

From: Eran Hammer <[email-masked]>
Date: Wed, 25 Apr 2012 14:41:11 +0000

Purely from a practical standpoint, do you think it is likely that a server will support the query filter for the lrdd documents but not for host-meta?

EH

From: [email-masked] [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Wednesday, April 25, 2012 6:17 AM
To: Paul E. Jones
Cc: [email-masked]
Subject: Re: [apps-discuss] WF flow with rel parameter

Paul,

John B.

John,

The "rel" parameter is something we still need to discuss, so not is as good a time as any.

What "rel" does is act as a filter.  For the most part, the only purpose it serves is to help reduce the number of link relations that might be sent from the server.  So, if a user had 1,000 different link relations, this might reduce the returned message to containing only 1.  However, if a user has more than one link relation of the same type, all of them would match and be returned.

The only URI template defined in RFC 6415 is "{uri}" (see 3.1.1.1).  There are no other URI template values defined.  (Note: this whole section exists only because RFC  6570 did not yet exist, I think.

In any case, we could define a new URI template, but then we would be putting an optimization in place for LRDD.  If host-meta is not going to support the "rel" URI parameter, why would LRDD?  It would also mean that the LRDD logic would have to be ready to receive a URI parameter that is not replaced, since some clients would only change {uri} and leave {rel} there.  That would introduce more conditional logic in the server.  This would also present issues with static sites.  (Of course, one might be able to use Apache re-writing rules to get around that problem, but it certainly would not work for "real" static sites.)

Personally,  I'd prefer to not add the "rel" parameter to LRDD, since I think optimization using "rel" would always be done on host-meta.  That said, I question the value of "rel" entirely.  Do you think it's useful to have this filter at all?  Is there really a risk that a site might return 1,000 link relations that the client would have to step over?

Paul

From: John Bradley [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Tuesday, April 24, 2012 10:17 PM
To: Paul E. Jones
Cc: [email-masked]<mailto:[email-masked]>
Subject: WF flow with rel parameter

Paul,

GET /.well-known/host-meta.json
     ?resource=[email-masked]<mailto:?resource=[email-masked]>
     &rel=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer HTTP/1.1
 Host: example.com<http://example.com/>

   HTTP/1.1 200 OK

   {
     "subject" : "[email-masked]<mailto:[email-masked]>",
     "links" :
     [
       {
         "rel" : "http://openid.net/specs/connect/issuer",
         "href" : "https://server.example.com<https://server.example.com/>"
       }
     ]
   }

GET /.well-known/host-meta.json
     ?resource=[email-masked]<mailto:?resource=[email-masked]>
     &rel=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer HTTP/1.1
 Host: example.com<http://example.com/>

HTTP/1.1 200 OK
           "https://example.com/lrdd/?format=json&resource={uri}<https://example.com/lrdd/?format=json&resource=%7buri%7d>"
       }

GET /lrdd/
     ?format=json
     &resource=[email-masked]<mailto:resource=[email-masked]>
 Host: example.com<http://example.com/>

HTTP/1.1 200 OK

   {
     "subject" : "[email-masked]<mailto:[email-masked]>",
     "links" :
     [
       {
         "rel" : "http://openid.net/specs/connect/issuer",
         "href" : "https://server.example.com<https://server.example.com/>"
       },
       {
         "rel" : "http://webfinger.net/rel/avatar",
         "href" : "http://example.com/~joe/joe.jpg"
       }

     ]
   }

Is it possible to have a template like:
"https://example.com/lrdd/?format=json&resource={uri}&rel={rel}<https://example.com/lrdd/?format=json&resource=%7buri%7d&rel=%7brel%7d>"

John B.

---

From: John Bradley <[email-masked]>
Date: Wed, 25 Apr 2012 11:48:32 -0300

Taking a closer look at http://tools.ietf.org/html/rfc6570

The lrdd template can be something like:
https://example.com/lrdd/?format=json{&uri,rel}
or
https://example.com/lrdd/?format=json&resource={uri}{&rel}

So it probably comes down to me asking for WF to conform to rfc6570 for LRDD template construction or at least adding the {?} and {&} templates from rfc6570.

That way people who want to host JRD's as a service on another host don't lose the ability to filter.

John B.

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 25 Apr 2012 11:01:37 -0400

John,

I actually did implement my server so that 'rel' is honored whether it's
given to host-meta or LRDD.  The reason is that it's actually the same
program.  It is a logical thing to have there for all the same reasons.

However, I am concerned with defining a URI template like '{rel}' that may
not be modified by the client.  So, what might happen is that a query might
be sent by the client that looks like this:

GET /lrdd/?resource=acct:[email-masked]&rel={rel}

The world would not end, but the server will have to know that the 'rel'
value of '{rel}' means no 'rel' parameter was actually passed.  I find that
a bit odd.

Why not just optimize on host-meta instead of LRDD?  I agree that WebFinger
is mostly an LRDD thing, but be mindful that querying host-meta, one gets a
set of link relations and querying LRDD one gets more link relations.  To
have all of the link relations for a specific resource, one must query both
host-meta and LRDD and merge the link relations (in the order received).  If
using the "resource" parameter on host-meta, then this merging of host-meta
resource-specific link relations (i.e., those that are "template" types) are
automatically merged in order with pure resource-specific link relations
returned by LRDD.

In any case, I have no strong objections, but we would have to have special
language about handling '{rel}' if the template is not substituted with a
real value.

Paul

From: John Bradley [mailto:[email-masked]] 
Sent: Wednesday, April 25, 2012 9:17 AM
To: Paul E. Jones
Cc: [email-masked]
Subject: Re: WF flow with rel parameter

Paul, 

"rel" as a filter is something WF has for host-meta.  It however doesn't
seem to have that for user JRD in the case where host-meta is returned, and
the template is used.

The "resource" and "rel" parameters are already an optimization for LRDD and
not part of host-meta.

Adding LRDD specific parameters to host-meta/host-meta.json will probably
raise some eyebrows in review, but I am OK with it.

I think there are use cases where size matters.  Where a host-meta or
resource JRD may be large and it is more efficient not to send the whole
thing to a mobile client.

Using RFC6570 for LRDD is a possibility for passing through the filter
request for sites that support filtering on resource JRD.

What other proposals do you have.  I am guessing that filtering on resource
JRD is not a totally new topic.

LRDD is the one really doing the optimization  in any event,  it may be done
at the host-meta GET but it is a LRDD specific extension.

Having it in the template allows LRDD to filter at the resource JRD in cases
where it is not possible to do it at the host-meta level, due to some no
script or other restriction.

I agree that it should be filtered at the how-meta request but you and
others say that is not always possible.

John B.

 

John,

Paul

Paul,

   HTTP/1.1 200 OK

   {

     "links" :

     [

       {

       }

     ]

   }

HTTP/1.1 200 OK

   {

     "links" :

     [

       {

         "rel" : "lrdd",

         "template" :

       }

GET /lrdd/

     ?format=json

HTTP/1.1 200 OK

   {

     "links" :

     [

       {

       },

       {

       }

     ]

   }

John B.

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 25 Apr 2012 11:06:16 -0400

Oh that would be worse.  A client that does not implement the "rel"
optimization (i.e., all current clients) would end up passing this to the
server:

https://example.com/lrdd/?format=json&resource=acct:[email-masked]{&rel}

So the value of "resource" is wrong.  We'd have to clean that up
server-side.  I don't like that.  I could live with looking for "rel={rel}'
and throwing away "{rel}".  Still, I have concerns about optimizing there.
I can see some benefit, but if we optimize on host-meta, that seems better.

Paul

> -----Original Message-----
> Sent: Wednesday, April 25, 2012 10:49 AM
> To: Paul E. Jones
> So it probably comes down to me asking for WF to conform to rfc6570 for
> LRDD template construction or at least adding the {?} and {&} templates
> from rfc6570.
> 
> > What "rel" does is act as a filter.  For the most part, the only purpose
> it serves is to help reduce the number of link relations that might be
> sent from the server.  So, if a user had 1,000 different link relations,
> this might reduce the returned message to containing only 1.  However, if
> a user has more than one link relation of the same type, all of them would
> match and be returned.
> >
> > When you say the host cannot support re-write rules, I assume you mean
> it does not support the URI parameters on host-meta?  In that case, yes,
> the parameters are ignored and you get just the host-meta document.
> >
> > The only URI template defined in RFC 6415 is "{uri}" (see 3.1.1.1).
> There are no other URI template values defined.  (Note: this whole section
> exists only because RFC  6570 did not yet exist, I think.
> >
> the LRDD logic would have to be ready to receive a URI parameter that is
> not replaced, since some clients would only change {uri} and leave {rel}
> there.  That would introduce more conditional logic in the server.  This
> would also present issues with static sites.  (Of course, one might be
> able to use Apache re-writing rules to get around that problem, but it
> certainly would not work for "real" static sites.)
> >

---

From: John Bradley <[email-masked]>
Date: Wed, 25 Apr 2012 12:26:32 -0300

That was one thing that initially confused me.  The rel filter is not applied to host-meta, but rather the linked lrdd resource JRD.

The currently defined "resource" parameter has an implicit host-meta "rel" of "lrdd".

To use this mechanism for other relations you would need to make that parameter explicit.

That then raises the question of the filter being part of host-meta or WF if it applies to relationships other than lrdd.

If you are asking if filtering should be supported by lrdd where you start discovery from a link header, then it probably should be possible as well.

Though I thought lrdd stopped being updated over a year a year ago.   Sorry if I am out of date.

So XRD/JRD documents SHOULD be filterable by "rel" independent of if you get to them via lrdd or host-meta.

Host-meta SHOULD support a mechanism to filter by "rel" or filter by a combination of "resource" (uri) , host-meta-rel and resource-rel (the host-meta-rel is currently implicit.)

I recall discussing this in the XRI TC when we did XRD years ago, though that was more around using XRI identifiers.

The same principal still holds.  I should be able to ask for.
GET /.well-known/host-meta.json
     ?resource=[email-masked]
     &host-meta-rel=lrdd
     &rel=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer HTTP/1.1
 Host: example.com

(personally I think calling the parameter "resource" and the template {uri} will be confusing to people)

In SWD we used fixed the parameter names and the base URI is the part that gets changed when the /.well-known can't host a script.
That makes the template simpler for the client to process.  The equivalent to "rel" is always passed to make processing simpler.

As Blaine has pointed out several times SWD and WF largely get us to the same place.

I am trying to find a way to close the gap.
 
John B.

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 25 Apr 2012 12:07:42 -0400

John,

> That was one thing that initially confused me.  The rel filter is not
> applied to host-meta, but rather the linked lrdd resource JRD.

It should be applied to all <Link>'s returned from a query to host-meta
where "resource" and "rel" parameters are used.  What I do is collect all
host-meta links and then all LRDD links (in order), then running the filter
over that after collecting all of the links.  (Memory optimization might be
to discard things that match right away, but it wasn't worth my time to see
if I can shave off milliseconds here.)
 
> The currently defined "resource" parameter has an implicit host-meta "rel"

Are you saying we implicitly filter only on LRDD links?  If so, that was not
the intent.  We should filter on ALL links that might be returned from the
query to host-meta. 

> To use this mechanism for other relations you would need to make that

The parameter is only documented for host-meta and documented in a section
called "The Web Host Metadata "rel" Parameter."  If that's not clear, we
should make it clear.  Suggestions?

> That then raises the question of the filter being part of host-meta or WF
> if it applies to relationships other than lrdd.

Only applies to host-meta queries (per the spec presently).
 
> If you are asking if filtering should be supported by lrdd where you start
> discovery from a link header, then it probably should be possible as well.

It's possible and my server would do that, as I mentioned.  I'm not sure how
useful it is.  If one believes it might be useful at host-meta level, then
it might be useful on LRDD only.  That said, I question both the usefulness
(since it merely reduces the document size) and I question why we don't
apply the "rel" filter at just one place if optimization is desired.
 
> Sorry if I am out of date.

The specs merged, but LRDD is its own resource.  It's not "host metadata",
but a resource-specific thing.
 
> get to them via lrdd or host-meta.

We could, but presently the spec intended to only applies this to host-meta.
My concern is with the construction of those templates, effect on existing
servers and clients, etc.
 
> Host-meta SHOULD support a mechanism to filter by "rel" or filter by a
> combination of "resource" (uri) , host-meta-rel and resource-rel (the
> host-meta-rel is currently implicit.)

The "rel" parameter when applied to /.well-known/host-meta should filter all
link relation values returned, regardless if those are resource-specific
that might have been expanded from LRDD or resource-specific as defined in
the host-meta document itself.  I have this working on my server.  See these
examples:

$ curl 'https://packetizer.com/.well-known/host-meta?
                  resource=acct:[email-masked]'
$ curl 'https://packetizer.com/.well-known/host-meta?
                  resource=acct:[email-masked]&rel=test'

The first returns the entire document.  The second returns only "test".
This "test" resource you can see came from host-meta:

$ curl 'https://packetizer.com/.well-known/host-meta'

> I recall discussing this in the XRI TC when we did XRD years ago, though
> that was more around using XRI identifiers.
> 

Given what I said, would we want the host-meta-rel parameter?  I don't think
we'd need it.
 
> {uri} will be confusing to people)

Why is this confusing?  What would be better?
 
> In SWD we used fixed the parameter names and the base URI is the part that
> gets changed when the /.well-known can't host a script.
> That makes the template simpler for the client to process.  The equivalent
> to "rel" is always passed to make processing simpler.

This is one difference :)
 
> As Blaine has pointed out several times SWD and WF largely get us to the

True.

Paul

---

From: Eran Hammer <[email-masked]>
Date: Wed, 25 Apr 2012 16:18:49 +0000

There are two separate issues here:

1. Adding support for RFC 6570 - this adds complexity (but might have happened if 6570 was finished earlier).
2. Define additional parameters (right now, only 'uri' is defined as a template input).

EH

> From: [email-masked] [mailto:apps-discuss-
> [email-masked]] On Behalf Of John Bradley
> Sent: Wednesday, April 25, 2012 7:49 AM
> To: Paul E.Jones
> LRDD template construction or at least adding the {?} and {&} templates from
> rfc6570.
> 
> serves is to help reduce the number of link relations that might be sent from
> the server.  So, if a user had 1,000 different link relations, this might reduce
> the returned message to containing only 1.  However, if a user has more than
> one link relation of the same type, all of them would match and be returned.
> >
> > The only URI template defined in RFC 6415 is "{uri}" (see 3.1.1.1).  There are
> no other URI template values defined.  (Note: this whole section exists only
> because RFC  6570 did not yet exist, I think.
> >
> present issues with static sites.  (Of course, one might be able to use Apache
> re-writing rules to get around that problem, but it certainly would not work
> for "real" static sites.)
> >
> > Personally,  I'd prefer to not add the "rel" parameter to LRDD, since I think
> optimization using "rel" would always be done on host-meta.  That said, I
> question the value of "rel" entirely.  Do you think it's useful to have this filter
> at all?  Is there really a risk that a site might return 1,000 link relations that the
> client would have to step over?
> >
> > Paul
> >

---

From: Eran Hammer <[email-masked]>
Date: Wed, 25 Apr 2012 16:34:14 +0000

It is important to understand the semantics of host-meta, which I think there is some confusion about here.

As a mechanism, host-meta providers you with a method of obtaining both host-wide and resource-specific links (and properties). To accomplish that, it provides with both a document and processing rules.

WebFinger - the name given for the host-meta *use-case* of retrieving user information - is a specialization of obtaining resource-specific links.

The 'rel' and 'resource' query parameters (as proposed) apply to the endpoint *after* executing the processing rules (which include expanding templates and importing links from one level LRDD documents).

LRDD documents only apply to resource-specific links, which means they are ignored for any host-wide query. For example, the location of the site's TOS document. From the host-meta perspective, LRDD documents are just a deployment tool to provide customization not possible using just link templates at the host-meta document level. It's just a link-include mechanism, and host-meta uses it restrictively.

IMO, the 'rel' and 'resource' optimization should only apply to the host-meta endpoint, and act as a filter post the processing rules. If 'resource' is specified, it is a resource-specific request, otherwise, host-wide.

Let me know if this helps or if it is still unclear.

EH

> Sent: Wednesday, April 25, 2012 8:27 AM
> To: Eran Hammer
> Cc: Paul E. Jones; [email-masked]
> That was one thing that initially confused me.  The rel filter is not applied to
> host-meta, but rather the linked lrdd resource JRD.
> 
> That then raises the question of the filter being part of host-meta or WF if it
> applies to relationships other than lrdd.
> 
> combination of "resource" (uri) , host-meta-rel and resource-rel (the host-
> meta-rel is currently implicit.)
> 
> That makes the template simpler for the client to process.  The equivalent to
> "rel" is always passed to make processing simpler.
> 
> > Purely from a practical standpoint, do you think it is likely that a server will
> support the query filter for the lrdd documents but not for host-meta?
> >
> > EH
> >
> > Adding LRDD specific parameters to host-meta/host-meta.json will
> probably raise some eyebrows in review, but I am OK with it.
> >
> > Using RFC6570 for LRDD is a possibility for passing through the filter request
> for sites that support filtering on resource JRD.
> >
> where it is not possible to do it at the host-meta level, due to some no script
> or other restriction.
> >

---

From: John Bradley <[email-masked]>
Date: Wed, 25 Apr 2012 14:37:32 -0300

Eran,

It was unclear, at least to me that the server side host-meta processing rule specified in WF requires all the templates (or just the LRDD ones) to be processed substituting inserting "resource" for URI and then retrieving and merging all the resource JRD before processing the filter on the "rel".

If I defined a rel of FOO would WF fill the template and retrieve the JRD and merge its links with the lrdd JRD?
I might think that would be a touch confusing to clients.

So I go back to the rational explanation that lrdd templates are expanded and those links rolled up and filtered.

Now I am guessing that some of the SWD people are thinking that when the server is using flat files that puts a lot of burden onto the client.

Probably why you added the server side processing.

Given that WF takes the liberty of adding query parameters to host-meta and seems to define host-meta processing rules (perhaps for non lrdd?), I am not finding the separation of the two specs as clean as possible.
It seems a bit like there is there a RFC 6415 dependency on WF.  Though that is a touch strange for a RFC.

What stops someone from defining a relation of super-discovery and adding some query parameters to host-meta.json to hover up some lrdd based on a template expansion of  "super-discovery" rel types, and filter on "rel"?

I wouldn't have thought to do that because stepping on the RFC 6415 endpoint seems slightly wrong to me.

I would probably define a new endpoint /.well-known/super-discovery with my own query parameters and processing rules for JRD documents. 

Without being able to make server-side processing of host-meta required,  we need someway to delegate that to another endpoint.  

In XRD we did discuss delegating the entire XRD.  Is there a way to do that in host-meta?

At the moment all of the processing gets pushed back on the client if the host only supports static files in /.well-known

John B.

---

From: Eran Hammer <[email-masked]>
Date: Wed, 25 Apr 2012 18:29:02 +0000

> Sent: Wednesday, April 25, 2012 10:38 AM
> To: Eran Hammer
> It was unclear, at least to me that the server side host-meta processing rule
> specified in WF requires all the templates (or just the LRDD ones) to be
> processed substituting inserting "resource" for URI and then retrieving and
> merging all the resource JRD before processing the filter on the "rel".
> 

No. It only does *one* level of LRDD import (in order). See:

http://tools.ietf.org/html/rfc6415#section-4.2

> Now I am guessing that some of the SWD people are thinking that when the
> server is using flat files that puts a lot of burden onto the client.
> 

The idea of adding server-side processing and filtering via the query came out of the original OpenID Connect proposal that David Recordon and I wrote, trying to keep the clients super simple and avoid the need to go fetch host-meta, then one or more LRDD documents.

Complexity is very much implementation specific on the server side. Yahoo doesn't have LRDD documents and puts everything as link templates in host-meta while others like the ability to customize. The most likely scenario of servers including LRDD links in host-meta is that the host-meta document is static, while the LRDD links are dynamically generated. Otherwise, there is very little value in the added complexity. In that case, the client will typically be faced with 2 requests.

I would argue that a server using multiple LRDD links in host-meta is abusing the system, very much like a server using multiple 3xx redirections between its initial host-meta endpoint to where the document actually lives.

IOW, there are many ways to inflict pain on the client.

> Given that WF takes the liberty of adding query parameters to host-meta
> and seems to define host-meta processing rules (perhaps for non lrdd?), I
> am not finding the separation of the two specs as clean as possible.

The WF draft should not introduce any new processing rules. It should only add the query optimization but that must result in exactly the same set of links as defined by 6415. If this is the case, it's a bug.

> What stops someone from defining a relation of super-discovery and adding
> some query parameters to host-meta.json to hover up some lrdd based on a
> template expansion of  "super-discovery" rel types, and filter on "rel"?
> 
> I would probably define a new endpoint /.well-known/super-discovery with
> my own query parameters and processing rules for JRD documents.

That would be the right approach. Note that 6415 registers both host-meta (defaults to XML) and host-meta.json (JSON required).

> Without being able to make server-side processing of host-meta required,
> we need someway to delegate that to another endpoint.
> 

3xx.

EH

> At the moment all of the processing gets pushed back on the client if the
> host only supports static files in /.well-known
> 
> John B.
> 
> 
> 
> > As a mechanism, host-meta providers you with a method of obtaining both
> host-wide and resource-specific links (and properties). To accomplish that, it
> provides with both a document and processing rules.
> >
> > WebFinger - the name given for the host-meta *use-case* of retrieving
> user information - is a specialization of obtaining resource-specific links.
> >
> > The 'rel' and 'resource' query parameters (as proposed) apply to the
> endpoint *after* executing the processing rules (which include expanding
> templates and importing links from one level LRDD documents).
> >
> > LRDD documents only apply to resource-specific links, which means they
> are ignored for any host-wide query. For example, the location of the site's
> TOS document. From the host-meta perspective, LRDD documents are just a
> deployment tool to provide customization not possible using just link
> templates at the host-meta document level. It's just a link-include
> mechanism, and host-meta uses it restrictively.
> >
> > IMO, the 'rel' and 'resource' optimization should only apply to the host-
> meta endpoint, and act as a filter post the processing rules. If 'resource' is
> specified, it is a resource-specific request, otherwise, host-wide.
> >
> >> The currently defined "resource" parameter has an implicit host-meta
> "rel"
> >> of "lrdd".
> >>
> >> Though I thought lrdd stopped being updated over a year a year ago.
> Sorry if
> >> I am out of date.
> >>
> >> So XRD/JRD documents SHOULD be filterable by "rel" independent of if
> you
> >> get to them via lrdd or host-meta.
> >>
> to
> >>> The "resource" and "rel" parameters are already an optimization for
> LRDD
> >> and not part of host-meta.
> request
> from
> are
> not
> Apache
> think

---

From: John Bradley <[email-masked]>
Date: Wed, 25 Apr 2012 16:00:15 -0300

OK so host-meta is one level of lrdd link processing for a resource (not host). 

Multiple lrdd links are not precluded, but are an abuse. 

If you want to redirect to an alternate host-meta location you use 3xx and the client will follow.
(I heard some complaining about what if my site can't support redirects earlier.)

The links are aggregated with host-meta links and filtered by "rel".

So if in host-meta I have: 
{
       "rel" : "http://openid.net/specs/connect/issuer",
       "href" : "https://server.example.com"
     }

before my lrdd entry

That would be returned in the filtered list before any resource specific "rel" ?

Thus making a global setting for all resources.  

I don't think the original Connect proposal had per user discovery only per host via host meta without following lrdd.

If aggrigating and sorting links are a requirement, that needs to be done server side for Connect clients.

John B.

---

From: Eran Hammer <[email-masked]>
Date: Wed, 25 Apr 2012 19:42:01 +0000

> Sent: Wednesday, April 25, 2012 12:00 PM
> To: Eran Hammer

Only if you change 'href' above to 'template'. 'href' are host-wide only and do not apply to resource-specific.

If you make a host-wide request, lrdd links and all templates are ignored.
If you make a resource-specific request, all href links in host-meta are ignored, templates expanded, and lrdd templates followed and included inline.

EH

> I don't think the original Connect proposal had per user discovery only per
> host via host meta without following lrdd.
> 
> >> If I defined a rel of FOO would WF fill the template and retrieve the JRD
> and
> >> merge its links with the lrdd JRD?
> >> So I go back to the rational explanation that lrdd templates are expanded
> and
> >> those links rolled up and filtered.
> >>
> > The idea of adding server-side processing and filtering via the query came
> out of the original OpenID Connect proposal that David Recordon and I
> wrote, trying to keep the clients super simple and avoid the need to go fetch
> host-meta, then one or more LRDD documents.
> >
> > Complexity is very much implementation specific on the server side. Yahoo
> doesn't have LRDD documents and puts everything as link templates in host-
> meta while others like the ability to customize. The most likely scenario of
> servers including LRDD links in host-meta is that the host-meta document is
> static, while the LRDD links are dynamically generated. Otherwise, there is
> very little value in the added complexity. In that case, the client will typically
> be faced with 2 requests.
> >
> > I would argue that a server using multiple LRDD links in host-meta is abusing
> the system, very much like a server using multiple 3xx redirections between
> its initial host-meta endpoint to where the document actually lives.
> >
> >> It seems a bit like there is there a RFC 6415 dependency on WF.  Though
> that
> >> is a touch strange for a RFC.
> >
> > The WF draft should not introduce any new processing rules. It should only
> add the query optimization but that must result in exactly the same set of
> links as defined by 6415. If this is the case, it's a bug.
> >
> > That would be the right approach. Note that 6415 registers both host-meta
> (defaults to XML) and host-meta.json (JSON required).
> >
> >> In XRD we did discuss delegating the entire XRD.  Is there a way to do that
> in
> >> host-meta?
> >
> > 3xx.
> >
> > EH
> >
> applied
> >>>> That then raises the question of the filter being part of host-meta or
> WF if
> >> it
> >>>> (personally I think calling the parameter "resource" and the template
> {uri}
> >>>> will be confusing to people)
> >>>>
> >>>> In SWD we used fixed the parameter names and the base URI is the
> part
> >> that
> >>>> As Blaine has pointed out several times SWD and WF largely get us to
> the
> >>>> same place.
> >>>>
> >>>> seem to have that for user JRD in the case where host-meta is
> returned,
> >> and
> >>>> the template is used.
> >>>>>
> >>>> the returned message to containing only 1.  However, if a user has
> more
> >> than
> There
> >>>> at all?  Is there really a risk that a site might return 1,000 link relations
> that
> >> the
> >>>>> WF allows for a JSON host-meta that takes two parameters,
> "resource"
> >> and
> >>>> "rel"
> >>>>>

---

From: John Bradley <[email-masked]>
Date: Wed, 25 Apr 2012 17:07:44 -0300

So the merged output if there is one in the host-meta and one in the resource JRD is more like:
"links" :
{
      "rel" : "http://openid.net/specs/connect/issuer",
      "template" : "https://server.example.com"
    },
{
      "rel" : "http://openid.net/specs/connect/issuer",
      "href" : "https://server.example.com"
    }
}

Is that correct?

John B.

On 2012-04-25, at 4:42 PM, Eran Hammer wrote:

>>>>>> was more around using XRI identifiers.
>>>>>>

---

From: Eran Hammer <[email-masked]>
Date: Wed, 25 Apr 2012 21:11:39 +0000

If your host-meta is:

{
  "links":[
    {
      "rel":"example",
      "href":"http://example.com/1"
    },
    {
      "rel":"lrdd",
      "template":"http://example.com/lrdd?resource={uri}"
    },
    {
      "rel":"example",
      "template":"http://example.com/2"
    }
  ]
}

And your LRDD document always return:

{
  "links":[
    {
      "rel":"example",
      "template":"http://example.com/3"
    }
  ]
}

Then a host-wide request:

GET /.well-known/host-meta.json?rel=example

Will return (I haven't checked the exact format of the latest draft so the syntax might be wrong here):

{
  "links":[
    {
      "rel":"example",
      "href":"http://example.com/1"
    }
  ]
}

And a resource-specific request (not escaped for readability):

GET /.well-known/host-meta.json?resource=http://example.com/resource

Will return:

{
  "links":[
    {
      "rel":"example",
      "href":"http://example.com/1"
    },
    {
      "rel":"example",
      "href":"http://example.com/2"
    }
  ]
}

Does this help?

EH

> Sent: Wednesday, April 25, 2012 1:08 PM
> To: Eran Hammer
> > If you make a resource-specific request, all href links in host-meta are
> ignored, templates expanded, and lrdd templates followed and included
> inline.
> >
> > EH
> >
> >>>> Now I am guessing that some of the SWD people are thinking that
> when
> >> the
> >>>> some query parameters to host-meta.json to hover up some lrdd
> based
> >> on a
> >>>>> It is important to understand the semantics of host-meta, which I
> think
> >>>> there is some confusion about here.
> >>>>>
> >>>>>> To use this mechanism for other relations you would need to make
> that
> >>>>>> parameter explicit.
> >>>>>>
> >>>>>>> Purely from a practical standpoint, do you think it is likely that a
> server
> >>>> will
> >>>>>>> LRDD is the one really doing the optimization  in any event,  it may
> be
> >>>> done
> >>>>>>> The "rel" parameter is something we still need to discuss, so not is
> as
> >>>> good
> >>>>>> a time as any.
> >>>>>>>
> >>>>>> does not support the URI parameters on host-meta?  In that case,
> yes,
> >>>> the
> >>>>>> no other URI template values defined.  (Note: this whole section
> exists
> >>>> only
> >>>>>>> In any case, we could define a new URI template, but then we
> would
> >> be
> >>>>>> support the "rel" URI parameter, why would LRDD?  It would also
> mean
> >>>> that
> >>>>>> the LRDD logic would have to be ready to receive a URI parameter
> that
> >> is
> >>>> not
> >>>>>> That would introduce more conditional logic in the server.  This
> would
> >> also
> >>>>>> re-writing rules to get around that problem, but it certainly would
> not
> >>>> work
> >>>>>> optimization using "rel" would always be done on host-meta.  That
> said,
> >> I
> >>>>>> question the value of "rel" entirely.  Do you think it's useful to have
> this
> >>>> filter
> >>>>>>> Let's set aside the XML issue for the moment and focus on the
> JSON
> >>>> flow.
> >>>>>>>
> >>>>>>> If the host can't support rewrite rules or scripts the exchange
> would
> >> look
> >>>>>> like:
> >>>>>>>
> >>>>>>> I can't find a template parameter for "rel".  The host-meta spec
> allows
> >>>> for
> >>>>>>> What if the server wants to support filtering on rel but can't
> support it
> >> in

---

From: John Bradley <[email-masked]>
Date: Wed, 25 Apr 2012 19:47:18 -0300

Thanks,

I think the example may be wrong though.

be:
> {
>  "links":[
>    {
>      "rel":"example",
>      "href":"http://example.com/3"
>    },
>    {
>      "rel":"example",

What bit of magic logic turns the template to a href in the response?   I would not have guessed that, part of my confusion.

So "template" gets expanded and  converted to href in the host-meta along with the "subject" becoming a canonical synonym for "resource"?

The "subject" value indicating that host side processing succeeded?

I feel like I am closer to understanding,  though perhaps farther away on convincing people of WF's simplicity for clients.

John B.

---

From: Eran Hammer <[email-masked]>
Date: Wed, 25 Apr 2012 22:56:03 +0000

> Sent: Wednesday, April 25, 2012 3:47 PM
> To: Eran Hammer
> > GET /.well-known/host-
> meta.json?resource=http://example.com/resource
> 
> be:
> > {
> >  "links":[
> >    {
> >      "rel":"example",

Yes, sorry. I was on a conference call and got distracted.

> What bit of magic logic turns the template to a href in the response?   I would
> not have guessed that, part of my confusion.

When you perform resource-specific discovery, you apply the resource URI to the templates. In this example, the template in host-meta just doesn't have any variables.

> So "template" gets expanded and  converted to href in the host-meta along
> with the "subject" becoming a canonical synonym for "resource"?
> 

This is part of the WF extension which I have not synced up on the recent draft. I think that's correct.

> I feel like I am closer to understanding,  though perhaps farther away on
> convincing people of WF's simplicity for clients.

The complexity comes from requirements in the original work:

1. Ability to represent data in static files / documents
2. Ability to define the order of links between the generic host-meta to the specific lrdd documents

We debated whether we should allow multiple lrdd documents, as well as if we should always process lrdd documents at the end. There are ways to simplify the processing rules (which are really pretty short and simple if you follow the specification and not try to reverse engineer the examples), but every simplification comes at reduced functionality.

The biggest difficulty is to decide what are the real requirements. Since this is a very generic discovery framework, everyone has an opinion and there isn't a clear answer that will make everyone happy.

EH

> > GET /.well-known/host-
> meta.json?resource=http://example.com/resource
> >
> > Will return:
> >
> > {
> >  "links":[
> >    {
> >      "rel":"example",
> >>>> If you want to redirect to an alternate host-meta location you use 3xx
> and
> >>>> the client will follow.
> >>> Only if you change 'href' above to 'template'. 'href' are host-wide only
> and
> >> do not apply to resource-specific.
> >>>
> >>>> If aggrigating and sorting links are a requirement, that needs to be
> done
> >>>> server side for Connect clients.
> >>>>
> >>>> John B.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>> It was unclear, at least to me that the server side host-meta
> processing
> >>>> rule
> >>>>>> processed substituting inserting "resource" for URI and then
> retrieving
> >>>> and
> >>>> servers including LRDD links in host-meta is that the host-meta
> document
> >> is
> >>>>>> I would probably define a new endpoint /.well-known/super-
> discovery
> >>>> with
> >>>>>>> As a mechanism, host-meta providers you with a method of
> obtaining
> >>>> both
> >>>>>> host-wide and resource-specific links (and properties). To
> accomplish
> >>>> that, it
> >>>>>> are ignored for any host-wide query. For example, the location of
> the
> >>>> site's
> >>>>>> TOS document. From the host-meta perspective, LRDD documents
> are
> >>>> just a
> >>>>>> meta endpoint, and act as a filter post the processing rules. If
> 'resource'
> >> is
> >>>>>>>> If you are asking if filtering should be supported by lrdd where
> you
> >> start
> >>>>>>>> discovery from a link header, then it probably should be possible
> as
> >>>> well.
> >>>>>>>>
> >>>>>>>> So XRD/JRD documents SHOULD be filterable by "rel"
> independent
> >> of if
> >>>>>> you
> >>>>>>>> Host-meta SHOULD support a mechanism to filter by "rel" or filter
> by
> >> a
> >>>>>>>>> I think there are use cases where size matters.  Where a host-
> meta
> >> or
> >>>>>>>>> What other proposals do you have.  I am guessing that filtering
> on
> >>>>>> resource
> >>>>>>>>> Having it in the template allows LRDD to filter at the resource JRD
> in
> >>>>>> cases
> >>>>>>>> where it is not possible to do it at the host-meta level, due to
> some
> >> no
> >>>>>> script
> >>>>>>>> or other restriction.
> >>>>>>>>>
> >>>>>>>>> I agree that it should be filtered at the how-meta request but
> you
> >> and
> >>>>>>>> the server.  So, if a user had 1,000 different link relations, this
> might
> >>>>>> reduce
> >>>>>>>> one link relation of the same type, all of them would match and
> be
> >>>>>> returned.
> >>>>>>>>>
> >>>>>>>>> When you say the host cannot support re-write rules, I assume
> you
> >>>>>> mean it
> >>>>>>>> putting an optimization in place for LRDD.  If host-meta is not
> going
> >> to
> >>>>>>>> replaced, since some clients would only change {uri} and leave
> {rel}
> >>>> there.
> >>>>>>>>> Personally,  I'd prefer to not add the "rel" parameter to LRDD,
> since
> >> I
> >>>>>> think

---

From: John Bradley <[email-masked]>
Date: Wed, 25 Apr 2012 20:07:52 -0300

Thanks,

Understood,  It isn't like people haven't accused me of not finding the function vs simplicity sweet spot myself:)

The static files requirement is a hard one to work around without having every client prepared to do the processing.

John B.

---

From: Eran Hammer <[email-masked]>
Date: Thu, 26 Apr 2012 01:24:56 +0000

I messed this up and ended up confusing everyone. Here is the corrected response:

If your host-meta is:

{
  "links":[
    {
      "rel":"example",
      "href":"http://example.com/1"
    },
    {
      "rel":"lrdd",
      "template":"http://example.com/lrdd?resource={uri}"
    },
    {
      "rel":"example",
      "template":"http://example.com/2?q={uri}"
    }
  ]
}

{
  "links":[
    {
      "rel":"example",

{
  "links":[
    {
      "rel":"example",

Will return:

{
  "links":[
    {
      "rel":"example",
      "href":"http://example.com/3"
    },
    {
      "rel":"example",
      "href":"http://example.com/2?q=http://example.com/resource"
    }
  ]
}

EH

> From: Eran Hammer
> Sent: Wednesday, April 25, 2012 2:12 PM
> To: 'John Bradley'
> Subject: RE: [apps-discuss] WF flow with rel parameter
> 
> If your host-meta is:
> 
> {
>   "links":[
>     {
>       "rel":"example",
> > >> OK so host-meta is one level of lrdd link processing for a resource
> > >> (not
> > host).
> > >>
> > >> (I heard some complaining about what if my site can't support
> > >> redirects
> > >> earlier.)
> > >>
> > > Only if you change 'href' above to 'template'. 'href' are host-wide
> > > only and
> > >> That would be returned in the filtered list before any resource
> > >> specific
> > "rel" ?
> > >>
> > >> I don't think the original Connect proposal had per user discovery
> > >> only per host via host meta without following lrdd.
> > >>
> > >>>> specified in WF requires all the templates (or just the LRDD
> > >>>> ones) to be processed substituting inserting "resource" for URI
> > >>>> and then retrieving
> > >> and
> > >>> The idea of adding server-side processing and filtering via the
> > >>> query
> > came
> > >> out of the original OpenID Connect proposal that David Recordon and
> > >> I wrote, trying to keep the clients super simple and avoid the need
> > >> to go
> > fetch
> > >> doesn't have LRDD documents and puts everything as link templates
> > >> in
> > host-
> > >> meta while others like the ability to customize. The most likely
> > >> scenario of servers including LRDD links in host-meta is that the
> > >> host-meta document
> > is
> > >> static, while the LRDD links are dynamically generated. Otherwise,
> > >> there is very little value in the added complexity. In that case,
> > >> the client will
> > typically
> > >>> I would argue that a server using multiple LRDD links in host-meta
> > >>> is
> > abusing
> > >>>> Given that WF takes the liberty of adding query parameters to
> > >>>> host-
> > meta
> > >>> The WF draft should not introduce any new processing rules. It
> > >>> should
> > only
> > >> add the query optimization but that must result in exactly the same
> > >> set of links as defined by 6415. If this is the case, it's a bug.
> > >>>
> > >>>> What stops someone from defining a relation of super-discovery
> > >>>> and
> > >> adding
> > >>>> I wouldn't have thought to do that because stepping on the RFC
> > >>>> 6415 endpoint seems slightly wrong to me.
> > >>>>
> > >>>> I would probably define a new endpoint
> > >>>> /.well-known/super-discovery
> > >> with
> > >>> That would be the right approach. Note that 6415 registers both
> > >>> host-
> > meta
> > >>>> In XRD we did discuss delegating the entire XRD.  Is there a way
> > >>>> to do
> > that
> > >> in
> > >>>> host-meta?
> > >>>
> > >>> 3xx.
> > >>>
> > >>> EH
> > >>>
> > >>>> At the moment all of the processing gets pushed back on the
> > >>>> client if
> > the
> > >>>>> LRDD documents only apply to resource-specific links, which
> > >>>>> means
> > they
> > >>>> deployment tool to provide customization not possible using just
> > >>>> link templates at the host-meta document level. It's just a
> > >>>> link-include mechanism, and host-meta uses it restrictively.
> > >>>>>
> > >>>>> IMO, the 'rel' and 'resource' optimization should only apply to
> > >>>>> the
> > host-
> > >>>>>> The currently defined "resource" parameter has an implicit
> > >>>>>> host-
> > meta
> > >>>> "rel"
> > >>>>>> of "lrdd".
> > >>>>>>
> > >>>>>> If you are asking if filtering should be supported by lrdd
> > >>>>>> where you
> > start
> > >>>>>> discovery from a link header, then it probably should be
> > >>>>>> possible as
> > >> well.
> > >>>>>>
> > >>>>>> Host-meta SHOULD support a mechanism to filter by "rel" or
> > >>>>>> filter by
> > a
> > >>>>>> I recall discussing this in the XRI TC when we did XRD years
> > >>>>>> ago,
> > though
> > >>>> that
> > >>>>>> support the query filter for the lrdd documents but not for
> > >>>>>> host-
> > meta?
> > >>>>>>>
> > >>>>>>> EH
> > >>>>>>>
> > >>>>>>> "rel" as a filter is something WF has for host-meta.  It
> > >>>>>>> however
> > doesn't
> > >>>>>>> The "resource" and "rel" parameters are already an
> > >>>>>>> optimization
> > for
> > >>>> LRDD
> > >>>>>>> I think there are use cases where size matters.  Where a
> > >>>>>>> host-meta
> > or
> > >>>>>> resource JRD may be large and it is more efficient not to send
> > >>>>>> the
> > >> whole
> > >>>>>>> What other proposals do you have.  I am guessing that
> > >>>>>>> filtering on
> > >>>> resource
> > >>>>>>> Having it in the template allows LRDD to filter at the
> > >>>>>>> resource JRD in
> > >>>> cases
> > >>>>>> where it is not possible to do it at the host-meta level, due
> > >>>>>> to some
> > no
> > >>>> script
> > >>>>>> or other restriction.
> > >>>>>>>
> > >>>>>>> What "rel" does is act as a filter.  For the most part, the
> > >>>>>>> only
> > purpose it
> > >>>>>> serves is to help reduce the number of link relations that
> > >>>>>> might be
> > sent
> > >>>> from
> > >>>>>> the server.  So, if a user had 1,000 different link relations,
> > >>>>>> this might
> > >>>> reduce
> > >>>>>>> Personally,  I'd prefer to not add the "rel" parameter to
> > >>>>>>> LRDD, since
> > I
> > >>>> think
> > >>>>>>> Content-Type: application/json; charset=UTF-8 {