Subject: Update on resource descriptor discovery work

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 11 May 2010 23:44:30 -0700

Just a quick update on the status of the various parts of the discovery work presented at the last IETF Apps meeting:

- What started as site-meta and changed into Well-known URIs is now RFC 5785 [1].
- Web Linking [2] was approved for RFC publication with a new registry for link relation types.
- XRD 1.0 [3] is moving to Committee Standard next week (OASIS).
- host-meta [4] is under review by the Apps area director and pending IETF last call.
- New draft available for LRDD [5], incorporating all the feedback received (mostly editorial), and hopefully ready for last-call in a week.
- First draft for 'acct' URI for accounts (as used by the WebFinger protocol [6]) is due shortly.

I'm starting to see the light at the end of the tunnel... :-)

If you care about any of this, it is critical to review the host-meta [4] and LRDD [5] documents. They are both short and include plenty of detailed examples. Feedback would be greatly appreciated on the Apps Discuss list.

EHL

[1] http://tools.ietf.org/html/rfc5785
[2] http://tools.ietf.org/html/draft-nottingham-http-link-header
[3] http://www.oasis-open.org/committees/download.php/37692/xrd-1.0-wd16.html
[4] http://tools.ietf.org/html/draft-hammer-hostmeta
[5] http://tools.ietf.org/html/draft-hammer-discovery
[6] http://hueniverse.com/2009/09/implementing-webfinger/

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 12 May 2010 22:56:05 -0400

Eran,

On host-meta:
Section 2 suggests that there may be one and only one hm:Host element.
Perhaps change the 'using the "hm:Host" element' to "using an "hm:Host"
element'?

In 3.1:
"The parent "XRD" element MUST include one but MAY include more"
Perhaps consider:
"The parent "XRD" element MUST include one or more"

In section 4:
Is there a reason for recommending use of HTTPS then HTTP?  Are there
situations where you think that the contents of the host-meta document might
need to be secured and would only be transmitted after mutual TLS
authentication?  In such a case, wouldn't a 3xx suffice?  It seems a bit
much to require use of HTTPS for what I believe is likely to be a
public-facing document.

You say that if the client receives a 3xx when trying to retrieve the
host-meta document, it SHOULD follow the redirection.  Can we make that a
MUST?  I think that would lend to better interoperability. That's also the
behavior specified in the LRDD draft.

References:
Web Linking reference needs updating.

On discovery (LRDD):

Section 1:
"...for the purpose of promoting interoperability and assist in interacting
with unknown resources that support known interfaces."
Change "purpose" to "purposes" (since you have more than one).
Should "assist" be "assisting"?  I think you'd agree that "for the purpose
of assist in ..." is not right.

Section 3, paragraph 3A: it is required to follow 3xx the first time it's
encountered, but only a "SHOULD" is specified if there are further
redirections.  As before, I would prefer to make that a MUST.  The warning
about loop detection is reasonable, though should be understood for any kind
of programmatic web service.  Keep it there, but don't let that issue be a
reason to not encourage following multiple redirections.  There is clearly a
limit of how many times a client might want to follow redirections, but I'd
prefer that to be more than 2 or 3.  (Same comment applies to 4.2 and 4.3.)

In Section 4.3, it states that tags in document markup must be processed
only on a 200?  What about a 304? You want to exclude use of the local
cache?

References: first two normative references need to be updated.

Paul

> -----Original Message-----
> From: [email-masked] [mailto:apps-discuss-
> [email-masked]] On Behalf Of Eran Hammer-Lahav
> Sent: Wednesday, May 12, 2010 2:45 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Update on resource descriptor discovery work
> 
> Just a quick update on the status of the various parts of the discovery
> work presented at the last IETF Apps meeting:
> 
> - New draft available for LRDD [5], incorporating all the feedback
> received (mostly editorial), and hopefully ready for last-call in a
> week.
> If you care about any of this, it is critical to review the host-meta
> [4] and LRDD [5] documents. They are both short and include plenty of
> detailed examples. Feedback would be greatly appreciated on the Apps
> Discuss list.
> 
> EHL
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 12 May 2010 22:51:13 -0700

> From: Paul E. Jones [mailto:[email-masked]]
> Sent: Wednesday, May 12, 2010 7:56 PM
> To: Eran Hammer-Lahav; [email-masked]
> Cc: [email-masked]
> Subject: RE: Update on resource descriptor discovery work
> 
> Eran,
> 
> On host-meta:

Section 2 starts by saying: "Each host-meta document describes one or more hosts". I think that makes it clear enough (as well as the examples).

> "The parent "XRD" element MUST include one or more"

Ok.

> situations where you think that the contents of the host-meta document
> might need to be secured and would only be transmitted after mutual TLS
> authentication?  In such a case, wouldn't a 3xx suffice?  It seems a bit much
> to require use of HTTPS for what I believe is likely to be a public-facing
> document.

It is a recommendation, not a requirement. Since this is a policy document which is likely to be used in protocols where trust plays a role, it is better to get libraries to optimize for this and attempt getting the HTTPS document first. The previous draft didn't place any preference and the feedback I got was that it would be better to define a preferred order.

> You say that if the client receives a 3xx when trying to retrieve the host-meta
> document, it SHOULD follow the redirection.  Can we make that a MUST?  I
> think that would lend to better interoperability. That's also the behavior
> specified in the LRDD draft.

LRDD doesn't mandate a MUST for host-meta, just for its own documents. But I have no problem making this a MUST. Anyone has an objection?
 
> Web Linking reference needs updating.

Yep. It will point to the RFC.

> On discovery (LRDD):
> 
> Section 1:
> "...for the purpose of promoting interoperability and assist in interacting with
> unknown resources that support known interfaces."
> Should "assist" be "assisting"?  I think you'd agree that "for the purpose of
> assist in ..." is not right.

Yep.

> about loop detection is reasonable, though should be understood for any
> kind of programmatic web service.  Keep it there, but don't let that issue be a

How would you describe such a MUST without requiring the client to follow, say, 100 redirections?

> In Section 4.3, it states that tags in document markup must be processed only
> on a 200?  What about a 304? You want to exclude use of the local cache?

Caching is allowed. A 304 just means the client can use a previously obtained document with a 200 status code. The client doesn't need to request anything if they have a valid copy in their cache. I think this is implied.

> References: first two normative references need to be updated.

Yep.

Thanks,

EHL

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 13 May 2010 12:24:30 -0400

Eran,

> It is a recommendation, not a requirement. Since this is a policy
> document which is likely to be used in protocols where trust plays a
> role, it is better to get libraries to optimize for this and attempt
> getting the HTTPS document first. The previous draft didn't place any
> preference and the feedback I got was that it would be better to define
> a preferred order.

That makes sense.

> follow, say, 100 redirections?

Why would it be different?  A 307 is a 307, right?  Perhaps I'm missing the
point.
 
> Caching is allowed. A 304 just means the client can use a previously
> obtained document with a 200 status code. The client doesn't need to
> request anything if they have a valid copy in their cache. I think this
> is implied.

It was implicit to me until I read that sentence.  My impression was that
you wanted to forbid use of the local cache for some reason.

Paul

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 13 May 2010 09:42:21 -0700

> Sent: Thursday, May 13, 2010 9:25 AM

> > > prefer that to be more than 2 or 3.  (Same comment applies to 4.2
> > > and
> > 4.3.)
> >

My concern is a MUST with potentially impractical repercussions (like following hundreds of redirections). In a browser this isn't an issue because there is a person sitting there with its own limit (how long the user is willing to sit there and stare at the URI changing without getting results). But for a client performing discovery, especially in UI sensitive applications, this can be a problem.

It would be helpful to know how other specifications handle such a requirement. Make it a MUST with a minimum number of redirections? Make it a MUST and assume the client will exit the loop as it see fit? Make it a SHOULD?

What's the best approach here in terms of language (since I think we agree on substance)?

> > request anything if they have a valid copy in their cache. I think
> > this is implied.
> 
> It was implicit to me until I read that sentence.  My impression was that you
> wanted to forbid use of the local cache for some reason.

What's the general approach in such cases? Should the spec explicitly call out the use of caching?

EHL

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 13 May 2010 13:50:42 -0400

Eran,

> My concern is a MUST with potentially impractical repercussions (like
> following hundreds of redirections). In a browser this isn't an issue
> because there is a person sitting there with its own limit (how long
> the user is willing to sit there and stare at the URI changing without
> getting results). But for a client performing discovery, especially in
> UI sensitive applications, this can be a problem.
> 
> It would be helpful to know how other specifications handle such a
> requirement. Make it a MUST with a minimum number of redirections? Make
> it a MUST and assume the client will exit the loop as it see fit? Make
> it a SHOULD?
> 

Good question.  RFC 2616 said:
      Note: previous versions of this specification recommended a
      maximum of five redirections. Content developers should be aware
      that there might be clients that implement such a fixed
      limitation.

There appears to be no specified maximum now.  It also says a client SHOULD
detect infinite loops, which I think is unfortunate, as I would have made it
a MUST.

I, too, would like to know why 5 was specified and why no limit is now
specified.  I think it does at least hint that 5 might be too restrictive,
but I don't know what general practice is.  I just checked some code I wrote
and, while it checks for loops, it imposed no limit on the number of
redirections.  How trusting I am ;-)
 
> call out the use of caching?

Had you not written that sentence that said to process HTML document only if
we receive a 200, I would have used the cached file if I received a 304.
I'd suggest having a statement that says the cached copy must be used if a
304 is returned.

Paul

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 25 May 2010 13:36:52 -0700

I removed the text about the extra redirection support. It just says you have to follow redirections and the rest is implied from 2616. As for 304, I think by saying that a 304 response is allows, using the caches copy is clearly implied (since the client did something to trigger this).

EHL

> Sent: Thursday, May 13, 2010 10:51 AM
> > requirement. Make it a MUST with a minimum number of redirections?
> > Make it a MUST and assume the client will exit the loop as it see fit?
> > Make it a SHOULD?
> >
> detect infinite loops, which I think is unfortunate, as I would have made it a
> MUST.
> 
> specified.  I think it does at least hint that 5 might be too restrictive, but I
> don't know what general practice is.  I just checked some code I wrote and,
> while it checks for loops, it imposed no limit on the number of redirections.
> How trusting I am ;-)
> 
> > > > > on a 200?  What about a 304? You want to exclude use of the
> > > > > local
> > > > cache?
> > > >
> Had you not written that sentence that said to process HTML document only
> if we receive a 200, I would have used the cached file if I received a 304.