Next steps on TAG ISSUE-60

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