- From: Johannes Koch <johannes.koch@fit.fraunhofer.de>
- Date: Wed, 03 Mar 2010 09:52:24 +0100
- To: ERT WG <public-wai-ert@w3.org>
Hi there, in <http://lists.w3.org/Archives/Public/public-earl10-comments/2009Dec/0004.html> Jonathan Rees suggested to add an Entity class to the HTTP-in-RDF vocabulary. Only entity headers would be associated with resources of type Entity. I guess, the other headers would still be associated to a Message resource. He also writes that this "would be useful in validating cache and proxy correctness, for example in accounting for the 'etag' header." I do not see that this is not possible with the current approach. Basically I see one major problem: HTTP-in-RDF represents the _structure_ of HTTP things, not the _semantics_. HTTP-in-RDF is header-purpose-agnostic. If we follow Jonathan's approach we have to distinguish entity headers from non-entity headers. HTTP 1.1 lists "general-header (section 4.5), request-header (section 5.3), response-header (section 6.2), and entity-header (section 7.1) fields". However, the IANA registry for message header field names does not give any indication about this classification (because it is a registry for message header field names, not _HTTP_ message header field names?). Even in RFC 4229 "HTTP Header Field Registrations" there's no indication. We could assume that the entity header field names listed in HTTP 1.1 section 7.1 are the only field names to be classified as entity header field names, meaning every field name to be registered with IANA apart from these cannot be an entity header field. But I don't know if this is a viable assumption. -- Johannes Koch Fraunhofer Institute for Applied Information Technology FIT Web Compliance Center Schloss Birlinghoven, D-53757 Sankt Augustin, Germany Phone: +49-2241-142628 Fax: +49-2241-142065
Received on Wednesday, 3 March 2010 08:52:59 UTC