“Design depends largely on constraints.” — Charles Eames
Friday, 25 July 2003
Mark Pilgrim is starting to think about issues surrounding the transport, transfer and general moving around of the Format Formerly Known as Echo (nee Pie).
This feels suspiciously like a profile of HTTP. We tried that a little bit in the Basic Profile, and I'm still undecided as to whether it was worthwhile or not.
That having been said, some thoughts and suggestions:
* Move away from RFC2119 language (MUST, SHOULD, MAY and friends) and make it more advisory. HTTP already has requirements that are very carefully thought out; adding new ones on top seems easy, but it's difficult to avoid the corner cases and not unduly restrict use of the protocol. Something more descriptive that has a lot of examples and explanations of why these are good things would be helpful.
* Be very precise when you're talking about the different parties in communication; "aggregator" is ambiguous (does FooApp qualify?) whereas "User Agent" is well-understood. This also fits in with the idea that there are a variety of ways to use syndicated content, not just in a desktop app.
* Likewise, be precise about what mode the agent is in; for example, it's appropriate to generate a blank Referer when polling, but when the software is following a link in the feed, it should be set to the feed URI.
* Rather than saying "unsubscribe" for things like 410 Gone status codes, say "cease polling"; agents might want to take other actions (e.g., alert the user, etc.), but the real point is that the agent doesn't poll anymore.
* Say more about the 300 status code or remove it; "treat it like 302" does it a disservice.
Filed under: Web
re: "Move away from RFC2119 language (MUST, SHOULD, MAY and friends)" I disagree strongly. "Friendly" specs with loose advisory language is one of the reasons we're in this mess to begin with.
And it's all well and good to say that "HTTP is well-specified", but you should see my logs sometime. Obviously the message isn't getting through to the developers of pretty much an entire class of applications. What's wrong with taking general rules (like RFC 2616) and creating specific rules/tests targeting one particular class of (misbehaving) applications?
Sunday, July 27 2003 at 12:27 PM +10:00
A similar point applies to terminology. The root of the flare-up about robots.txt support was that Kevin didn't feel that NewsMonster qualified as a crawler (despite the fact that it was following links and downloading resources recursively). RFC 2616 is written to be as specific as possible, to cover everyone in the known universe who wants to do anything over HTTP. That's not the kind of spec I'm writing.
Sunday, July 27 2003 at 12:31 PM +10:00
Of course I meant to say "RFC 2616 is written to be as *general* as possible"...
Sunday, July 27 2003 at 12:31 PM +10:00