RE: [metadataInURI-31] Update on Use of Metadata in URIs Draft

Hi Noah,
 
I think the following URI is useful; 
 
http://www.hixie.ch/tests/adhoc/http/content-type/
 
The issue is many of these files are are supposed to be text.html but
are in fact other file types.  The browser ignores the file type and
attempts to interpret the file by extension.  We should either eliminate
the file type (Ignore it) and enforce file extensions or we should
enforce file-type and ignore file extensions.  Seems like we're
inconsistent.
 
My take on this is that users are becoming better educated in their use
of the web and when the click on a .rss file they expect to see an RSS
feed instead of an xml file or an html file.
 
Hope this helps.
-Ed
 

________________________________

From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] On Behalf
Of noah_mendelsohn@us.ibm.com
Sent: Monday, October 23, 2006 7:21 AM
To: www-tag@w3.org
Subject: [metadataInURI-31] Update on Use of Metadata in URIs Draft



I have an action to update the last section of the metadataInURI draft.
I am well along in doing the editing, but somewhat behind where I'd
hoped to be.  Specifically, it should be clear that I have blown the due
date of Oct. 20.   I will be traveling from this afternoon thru
Thursday.  With luck, I'll find time to wrap things up while I'm on the
road, but failing that probably while I'm on the plane to the Schema
meeting next Sunday.   Note that I have already sent probable regrets
for tomorrow's call (and for next week's).  I'll get the draft out as
soon as I can, and we can figure out when to discuss once I do. 

I would appreciate it if other concerned TAG members would doublecheck
whether I've correctly heard the instructions from Vancouver [1].
Honestly, I still am having some trouble convincing myself that the
story we told there (I.e. the one you asked me to tell in the finding)
is entirely about URIs.  The story in a nutshell: 

"Bob sees image on screen, right clicks to save, winds up with
executable, is unhappy." 

I think the implied markup is along the lines of: 

Variant 1: 

<a href="http://malicious.example.com/image.exe">   
  <img src="http://malicious.example.com/image.jpg"> 
</a> 

though the inner URI suffix doesn't seem to matter too much, as it's
unlikely to be shown to the user or used as a point of type inference by
the browser's rendering logic.   Am I thinking right about the markup
you have in mind?  If so, then I think the confusion is mainly about the
existence of two URIs, and only secondarily about their suffixes or
metadata.  I think Bob would be at least as confused if we had: 

Variant 2: 

<a href="http://malicious.example.com/image1">  <!-- served as
executable mime type --> 
  <img src="http://malicious.example.com/image2">  <!-- served as
image/jpeg --> 
</a> 

He'd still be looking at an image, still right mouse, and if the browser
honored the media type would wind up with an executable, perhaps with a
filename ending in .exe. 

The only place URI confusion seems to come in is if we additionally
assume a browser that, in violation of Web architecture (though in
keeping with all too common practice), blindly preserves the URI suffix
when writing to the OS filesystem.  Even in that case, the chances that
Bob knows something is wrong are a bit higher in Variant 1, because he
might see the .exe in the URI being saved and might guess that his
browser violates Web architecture by honoring the URI suffix in
preference to the media type.  In either variant, Bob can: "see image,
right click, save, be unhappy".    That seems to show that URI metadata
is a secondary, not primary issue here.  The main reason I see that URI
metadata matters is the happenstance that there aren't ubiquitously
deployed media/type conventions for serving executables to certain
platforms, so using the .exe suffix may be needed to trick the browser
into saving as executable.  I'm assuming the story you want me to tell
is grounded in that whole messy combination of interacting factors,
which together lead to Bob unexpectedly saving an executable when he
thought he was saving an image. 

Notwithstanding the above questions, I'm well along in telling a simple
overall story about confusion regarding URI suffixes, about filesystems
and their use of filename suffixes etc.  Indeed, I have a writeup that
tells the story of variant 1, concluding:   

"Note that some of the confusion in these examples arises merely from
the distinction between the image resource shown on the screen, and the
content linked from the anchor that includes the image;  the confusion
is potentially compounded by the tendency of users, browsers, and
operating systems, each in their own way, to infer type information from
URI and/or filename suffixes." 

I just wanted to doublecheck that this is indeed the story you were
asking me to tell.  You probably saw in Vancouver that I was having some
trouble internalizing it, and to some extent still am.   My confusion
arises, I think (a) from not noticing at first that the story involves
two URIs, one for the rendered image and one for the anchor; and (b)
because it's not clear that confusion about URI metadata is the
fundamental problem in this case, as illustrated in variant 2.  Am I
again missing something?  If not, I'll wrap it up in draft form and
circulate ASAP.  Thank you. 

Thank you. 

Noah 

[1] http://www.w3.org/2001/tag/2006/10/04-tagmem-minutes#item02 

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------