Media/Device Type Spec???
dave at cridland.net
Fri Aug 20 11:43:17 EEST 2004
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
> > > 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
> 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.
More information about the xdg