Profiling HTTP
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.