- From: <noah_mendelsohn@us.ibm.com>
- Date: Wed, 20 May 2009 18:03:09 -0400
- To: "T.V Raman" <raman@google.org>
- Cc: www-tag@w3.org
Raman, In preparation for the upcoming F2F, you encouraged the TAG to think about next steps for ISSUE-60, and for the working draft [1]. I've given this just a bit of thought, which I hope may be useful in jumpstarting the discussion. The abstract says: "The goal of this finding is to initially collect the various usage scenarios that are leading to innovative uses of client-side URL parameters, along with the solutions that have been developed by the Web community. When this exercise is complete, this finding will conclude by ensuring that these design patterns are mutually compatible. If some of these usage patterns are identified as being in conflict, we will recommend best practices that help side-step such conflicts." So, we should at least study that question. Do you have any insights as to whether we have seen such conflicts, and if so where? Also, here are some other directions that I think might be appropriate for this finding: * I think it would be interesting to explain to the community, possibly with a worked example or two, which RFCs, Recommendations, and TAG Findings apply, starting most obviously with RFC 3986. What normative specifications allow you to determine that the browser is rendering the correct content for each synthesized client URI? * As I've mentioned before, one aspect of that I'd like to explore is the relationship between client side URIs and media type specifications, given that media type specifications are in many cases the authoritative documentation for fragment syntax and semantics. Are they here too? So, that's an example of explaining which specifications apply. * I think it might be interesting to dig a bit into the distinction between client side URIs that are purely private to a particular browser instance, vs. those that can be seen in, say, the addresess bar, and from there copied and pasted into (for example) emails, and sent to other users. If I get hold of the URI for a video frame in the the middle of a CNN feed, can I email it to you and have it work (show you the video from that point) when you click it? Why or why not? * What if I try to invent my own URI that looks like it matches the template of one of these client-side URIs? In that context, it may be worth considering the connection with the TAG's Metadata in URI finding [2]. In particular, I think there may also be some parallel with the HTML Forms example in section 2.3 of the metdata finding[3]. In both cases, we have forms/scripts sent from a server that assemble URIs in a stylized way at the client. It might be interesting to draw attention to the paragraph in [3] that says: "Note that the example carefully specifies that the HTML form is sourced from the same authority as the individual weather URIs that the form queries. In fact, it is also common for the ACTION attributes in HTML forms to refer to URIs from other authorities. In such cases, it is the provider of the form rather than the assigning authority for the queried URIs who is responsible for the claims made in the form. In particular, users (and software) should check the origin of HTML forms before depending on the URI assignment patterns that they appear to imply. Of course, you can always use such a form to perform a query and see what comes back; what you can't do is blame the assignment authority if the generated URIs either don't resolve (status code 404) or return representations that don't match the expectations established when reading the form (you got a football score instead of a weather report). " In short, I think there may be an interesting story to tell about who gets to synthesize these URIs, and which normative specifications determine who has authority over their binding to resources. I'm in a bit of a rush tonight and may not have expressed that all as carefully as I should, but I think it should be clear some of the areas that I think we might discuss. Noah [1] http://www.w3.org/2001/tag/doc/hash-in-url [2] http://www.w3.org/2001/tag/doc/metaDataInURI-31.html [3] http://www.w3.org/2001/tag/doc/metaDataInURI-31.html#forms -------------------------------------- Noah Mendelsohn IBM Corporation One Rogers Street Cambridge, MA 02142 1-617-693-4036 --------------------------------------
Received on Wednesday, 20 May 2009 22:01:48 UTC