Add me as a +1 for the idea that content-type is important for this. I tend to agree with the arguments given so far. Namely, for some important use cases you're going to want to know the content type and guessing is really a bad idea. That said, there are security considerations associated with specifying a content type too. I'm particularly imagining a situation where some sort of deep inspection security appliance uses a different procedure for deciding what kind of foo it is than the ultimate application. One guesses based on byte stream another looks at a content type. This is well known; it's not new; it's probably even so documented that any reasonably current set of MIME security considerations already includes a reference. I agree that your draft does not use the authority portion of a URI consistent with section 3.2 of RFC 3986. The authority separates the namespace exactly the way it doesn't in your scheme. It's a naming hierarchy. My main concern is whether the relative reference algorithm described in section 5/4.2 of RFC 3986. In particular take a look at the last part of section 1.2 of RFC 3986 regarding the disallowing of /. Consider how you want relative references in an HTML document resolved through a ni: URI to work. I don't think your use of authority provides good results. However I'm not sure that better results would be achieved without hierarchy. I hope though that these comments will help inject some ways of reasoning about authority that are less mystical and that lead to more practical discussion.