Personally, I think Informational is most appropriate (and probably easier), but a paragraph or two of context, as well as corresponding adjustments, would work as well.
Cheers, On 13/07/2011, at 5:36 AM, Peter Saint-Andre wrote: > On 6/21/11 11:08 PM, Mark Nottingham wrote: >> Generally, it's hard for me to be enthusiastic about this proposal, >> for a few reasons. That doesn't mean it shouldn't be published, but I >> do question the need for it to be Standards Track as a general >> mechanism. > > How about publishing it on the standards track but not as a general > mechanism (i.e., why not clarify when it is and is not appropriate)? > > Clearly, both service providers (Google, Yahoo, etc.) and spec authors > (draft-hardjono-oauth-dynreg-00, draft-hardjono-oauth-umacore-00) have > found hostmeta somewhat useful in certain contexts. > > RFC 2026 says: > > A Proposed Standard specification is generally stable, has resolved > known design choices, is believed to be well-understood, has received > significant community review, and appears to enjoy enough community > interest to be considered valuable. > > and: > > Usually, neither implementation nor operational experience is > required for the designation of a specification as a Proposed > Standard. However, such experience is highly desirable, and will > usually represent a strong argument in favor of a Proposed Standard > designation. > > The spec seems to be stable at this point, it's received significant > review, people seem to understand what it does and how it works, it's > had both implementation and operational experience, and it appears to > enjoy enough community interest to be considered valuable in certain > contexts. I also think it has resolved the design choices and solved the > requirements that it set out to solve, although you might be right that > it doesn't solve all of the problems that a more generic metadata > framework would need to solve. > > As a result, it seems like a fine candidate for Proposed Standard, i.e., > an entry-level document on the standards track that might be modified or > even retracted based on further experience. > >> Mostly, it's because I hasn't really seen much discussion of it as a >> general component of the Web / Internet architecture; AFAICT all of >> the interest in it and discussion of it has happened in more >> specialised / vertical places. > > Again, perhaps we need to clarify that it is not necessarily a general > component of the web architecture, although it can be used to solve more > specific problems. > >> The issues below are my concerns; >> they're not insurmountable, but I would have expected to see some >> discussion of them to date on lists like this one and/or the TAG list >> for something that's to be an Internet Standard. >> >> >> * XRD -- XRD is an OASIS spec that's used by OpenID and OAuth. Maybe >> I'm just scarred by WS-*, but it seems very over-engineered for what >> it does. I understand that the communities had reasons for using it >> to leverage an existing user base for their specific user cases, but >> I don't see any reason to generalise such a beast into a generic >> mechanism. > > As discussed in responses to your message, XRD seems to have been an > appropriate tool for the job in this case. Whether XRD, too, is really a > general component of the web architecture is another question. > >> * Precedence -- In my experience one of the most difficult parts of a >> metadata framework like this is specifying the combination of >> metadata from multiple sources in a way that's usable, complete and >> clear. Hostmeta only briefly mentions precedence rules in the >> introduction. > > That could be something to work on if and when folks try to advance this > technology to the next maturity level (currently Draft Standard). > >> * Scope of hosts -- The document doesn't crisply define what a "host" >> is. > > This seems at least somewhat well-defined: > > a "host" is not a single resource but the entity > controlling the collection of resources identified by Uniform > Resource Identifiers (URI) with a common URI host [RFC3986]. > > That is, it references Section 3.2.2 of RFC 3986, which defines "host" > with some precision (albeit perhaps not "crisply"). > >> * Context of metadata -- I've become convinced that the most >> successful uses of .well-known URIs are those that have commonality >> of use; i.e., it makes sense to define a .well-known URI when most of >> the data returned is applicable to a particular use case or set of >> use cases. This is why robots.txt works well, as do most other >> currently-deployed examples of well-known URIs. >> >> Defining a bucket for potentially random, unassociated metadata in a >> single URI is, IMO, asking for trouble; if it is successful, it could >> cause administrative issues on the server (as potentially many >> parties will need control of a single file, for different uses -- >> tricky when ordering is important for precedence), and if the file >> gets big, it will cause performance issues for some use cases. > > It would be helpful to hear from folks who have deployed hostmeta to > hear if they have run into any operational issues of the kind you > describe here. > >> * Chattiness -- the basic model for resource-specfic metadata in >> hostmeta requires at least two requests; one to get the hostmeta >> document, and one to get the resource-specific metadata after >> interpolating the URI of interest into a template. >> >> For some use cases, this might be appropriate; however, for many >> others (most that I have encountered), it's far too chatty. Many use >> cases find the latency of one extra request unacceptable, much less >> two. Many use cases require fetching metadata for a number of >> distinct resources; in this model, that adds a request per resource. >> >> I'd expect a general solution in this space to allow describing a >> "map" of a Web site and applying metadata to it in arbitrary ways, so >> that a client could fetch the document once and determine the >> metadata for any given resource by examining it. > > That sounds like good input to a more generic approach. Many discovery > protocols do seem to have an inherent chattiness about them, but you > might be right that ideally the round trips could be kept to a minimum. > >> If hostmeta is designed for specific use cases and meets them well, >> that's great, but it shouldn't be sold as a general mechanism. So, >> I'm -1 on this going forward as a standards-track general mechanism. >> I wouldn't mind if it were Informational, or if it were >> Standards-Track but with a defined use case. > > Again, I think some clarifying language about the applicability of the > technology is in order. > >> Apologies for giving this feedback so late in the process; I knew >> hostmeta was there, just didn't have time to step back and think >> about it. > > And my apologies for taking so long to reply. > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > -- Mark Nottingham http://www.mnot.net/ _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
