RE: Update on resource descriptor discovery work

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: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
> bounces@ietf.org] On Behalf Of Eran Hammer-Lahav
> Sent: Wednesday, May 12, 2010 2:45 AM
> To: discuss@apps.ietf.org
> Cc: www-tag@w3.org
> 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:
> 
> - 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/
>

Received on Thursday, 13 May 2010 02:57:39 UTC