[uf-rest] Roy Fielding on WebDAV and PROPs

[Mark Nottingham]

It = your scheme for using semicolons for a particular purpose, not  
the reserved character itself.

Claiming a reserved character for a particular use world-wide breaks  
URI opacity, in the same way that the P3P specification says that you  
have to place a file at /w3c/p3p.xml breaks URI opacity.

Considering that there are already people that use semicolons for  
site-specific purposes (e.g., matrix URIs), standardising (and that's  
the important word) on them for accessing properties will cause  
collisions.

For example, if you have an exisitng site using WebDAV, and you want  
to change it to this convention, you'll have problems if you have  
existing resources with semicolons in their URIs.

That's why I suggested that a site-configurable convention would be  
more useful.


On 2006/04/11, at 9:14 PM, Breton Slivka wrote:

> err, it isn't? if the generic syntax isn't defined in 2396, where  
> is it defined?
>
>
> On Apr 11, 2006, at 8:24 PM, Mark Nottingham wrote:
>
>>  this isn't defined in the generic syntax or in the HTTP scheme.
>>
>> Cheers,
>>
>>
>>
>> On 2006/04/11, at 5:22 PM, Breton Slivka wrote:
>>
>>> 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
>>>    references."
>>>
>>> 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
>>>
>>> http://www.hostname.com/database/ 
>>> object;property1;property2;property3/ 
>>> subobject;property4;property5;property6
>>>
>>> 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
>>>
>>> _______________________________________________
>>> microformats-rest mailing list
>>> microformats-rest at microformats.org
>>> http://microformats.org/mailman/listinfo/microformats-rest
>>>
>>
>>
>> --
>> Mark Nottingham     http://www.mnot.net/
>>
>> _______________________________________________
>> microformats-rest mailing list
>> microformats-rest at microformats.org
>> http://microformats.org/mailman/listinfo/microformats-rest
>
> _______________________________________________
> microformats-rest mailing list
> microformats-rest at microformats.org
> http://microformats.org/mailman/listinfo/microformats-rest
>


--
Mark Nottingham     http://www.mnot.net/