[uf-rest] Roy Fielding on WebDAV and PROPs

Breton Slivka zen at zenpsycho.com
Tue Apr 11 17:22:51 PDT 2006

rfc2396 briefly mentions in section 3.3:

"The path may consist of a sequence of path segments separated by a
    single slash "/" character.  Within a path segment, the characters
    "/", ";", "=", and "?" are reserved.  Each path segment may  
include a
    sequence of parameters, indicated by the semicolon ";" character.
    The parameters are not significant to the parsing of relative

it further mentions

"Extensive testing of current client applications demonstrated that
    the majority of deployed systems do not use the ";" character to
    indicate trailing parameter information, and that the presence of a
    semicolon in a path segment does not affect the relative parsing of
    that segment.  Therefore, parameters have been removed as a separate
    component and may now appear in any path segment.  Their influence
    has been removed from the algorithm for resolving a relative URI
    reference.  The resolution examples in Appendix C have been modified
    to reflect this change."

It doesn't seem to go into much more detail about what a "parameter"  
is, so I will assume for now (unless someone can find the relevant  
documentation on this) that it is up to the specific application to  
determine the usage for these paramaters. THEREFORE, one can use  
semicolon parameters to retrieve properties from resources like so


it is possible then, to standardize on at least one parameter name  
which would return a list of available properties, or simply return  
all available properties. Individual properties can be retrieved  
using URI scheme as above.

HOW these properties are returned to the client is another matter.  
Whether it is through metatags, or header information, I have no idea  
which is best. But I thought it would be somewhat useful to the  
conversation to throw in that oft forgotten and unused reserved  
character in URI naming schemes: The semicolon.

On Apr 11, 2006, at 3:32 PM, Dr. Ernie Prabhakar wrote:

> I've always felt there was something wrong with WebDAV, and Roy did  
> a nice summary of what over on rest-discuss:
> On Apr 11, 2006, at 12:40 PM, Roy T. Fielding wrote:
>> PROP* methods conflict with REST because they prevent
>> important resources from having URIs and effectively double the
>> number of methods for no good reason.  Both Henrik and I argued
>> against those methods at the time.  It really doesn't matter
>> how uniform they are because they break other aspects of the
>> overall model, leading to further complications in versioning
>> (WebDAV versioning is hopelessly complicated), access control
>> (WebDAV ACLs are completely wrong for HTTP), and just about every
>> other extension to WebDAV that has been proposed.
> The interesting question for me is what the "right" way to do  
> properties would be over HTTP.  I presume it would require some  
> sort of convention for a property namespace, which implies non- 
> opaque URLs.  Which in term (in order to be RESTful) would require  
> the *server* to have some way to tell clients about it, since  
> clients shouldn't *assume* URI structure.
> Any thoughts about the optimal way to do that?
> -- Ernie P.
> _______________________________________________
> microformats-rest mailing list
> microformats-rest at microformats.org
> http://microformats.org/mailman/listinfo/microformats-rest

More information about the microformats-rest mailing list