Media/Device Type Spec???

[Dave Cridland]

On Fri Aug 20 08:15:07 2004, Alexander Larsson wrote:
> On Thu, 2004-08-19 at 13:07, Waldo Bastian wrote:
> > On Thursday 19 August 2004 12:03, Dave Cridland wrote:
> > > The upshot of this is that some service types are more specific
> > > versions of others, potentially. How compatible do you think 
> this
> > > concept is with existing usage of KDE's service types?
> > > Wrt to more specific versions of others, we have service type 
> inheritance > which allows to create specialized service types.
> > > We don't have a good solution for the "http-URI is actually 
> subversion" > problem. For WebDAV we have created a separate 
> webdav-URI to be able to > distinguish the different capabilities 
> in comparison to common http.
> 
> We have the same issue in gnome. For this particular issue we added 
> dav:
> and davs:

My problem with that is threefold:

1) It breaks the useful ability to be able to throw a Subversion HTTP 
URI at the webbrowser, or an innocent person.
2) 'dav' scheme is registered, but means something else, 'davs' is 
not. [dav: is a URN used for XML namespacing]
3) Finally, it's not a generic solution - there's an increasing 
number of protocol overloads being defined based on DAV. 'Defining' 
URI schemes for each of them fragments the URI space, and prevents 
them from being treated as plain DAV or HTTP, both of which being 
useful properties, and, one would hope, the reason they're defined as 
being HTTP/DAV overloads.

I've been trying to figure out a way to include this kind of 
information in a URI without breaking existing apps - the closest I 
can think of is using an otherwise illegal fragment identifier, such 
as '#?dav?x-svn' or something. Obviously URIs with an existing 
fragment identifier could break at this point, but my testing so far 
suggests it won't have any impact on servers, so that's something. 
This is, of course, a job for the IETF, not us, but it'd be nice if 
we could come up with a sensible method here to draft up.

Some examples of protocols which are overloaded HTTP:

a) DAV, obviously.
b) DeltaV (DAV with extras)
c) Subversion/HTTP (DeltaV with extras)
d) XCAP (HTTP with funny URIs and, IIRC, extra ETags)
e) *DAV (For instance, CalDAV, et al: All DAV with bells on)

Obviously, this kind of protocol overloading makes little sense in 
many cases - possibly even most cases - but it does make sense in 
some. (Like DAV, Subversion, and, erm... Probably others.)

But aside from my personal viewpoint on whether the overloads 
themselves are sensible or not, they exist, and a better method of 
handling them needs to be found.

Defining new URIs eradicates the use of overloading HTTP in the first 
place, assuming there was any.

Dave.