[
Lists Home |
Date Index |
Thread Index
]
> From: Gavin Thomas Nicol [mailto:gtn@rbii.com]
> Sent: Thursday, December 20, 2001 5:00 PM
> To: xml-dev@lists.xml.org
> Subject: Re: [xml-dev] Some comments on the 1.1 draft
>
>
> On Thursday 20 December 2001 05:27 am, Julian Reschke wrote:
> > > No, but things like the lack of versioning, locking being
> > > optional, etc. etc.
> >
> > Versioning is specified in the WebDAV deltav extension, which has been
> > submitted to the IESG in October.
>
> Not *yet* ratified. I guess DASL et al. are coming too. Still,
> these add a
> lot to an already shaky specification.
I prefer to have layered specifications, and not to specify until the
problem is well understood and enough people are interested.
> > And why is the fact that locking is optional a problem? If you
> hit a server
> > that doesn't support locking while youre application requires it -- just
> > don't talk to it. I agree that it would be a shame if major vendors come
> > out with "WebDAV" servers without locking support (is this the case? IIS
> > and Apache support it).
>
> One of the things I've learnt over time is that you cannot rely
> upon those
> things that are optional. Assuming that all servers will support
> it is not
I don't assume that. I just live with the fact that a server may say it's
doing WebDAV, but doesn't do locking. What would you gain by forbidding the
term "WebDAV"? The server would still need to implement resource discovery
(PROPFIND), namespace manipulations (COPY, DELETE, MKCOL). Do you think that
these features are useless without locking?
> good enough.... a case in point here is the way properties are handled by
> existing clients. The specification is very unclear about ordering of
> properties and response blocks. The specification, if read one way, would
They aren't ordered.
> allow every reponse for every resource to be separate. Most clients can't
> handle this. Another one is the special header needed for MS
So this may need to be clarified. That's not unexpected for something which
is a proposed protocol only.
> clients to work
> (not in the specification).
That's a bug in the Microsoft client. Don't blame the protocol for this kind
of implementation bugs.
> WebDAV interoperability has more to do with the small size of the overall
> community (tribal knowledge) than it does with clarity or correctness of
> specification.
Yes and no. I agree that RFC2518 needs more work to go into the next stage
in the standardization process, but I doub't you'll find a single person in
the Working Group disagreeing with that. In fact, there's a long list of
known issues which need to be resolved for this next step.
> > > a) circumvent firewall issues
> >
> > Actually, I'd say the fact that WebDAV uses well-defined HTTP
> method names
> > makes it *less* likely that security is compromised (as
> compared to XML-RPC
> > or SOAP).
>
> C'mon, using port 80 for is a kludge.... just like using finger
> back in the
> old days was. While some firewalls allow you to block individual HTTP
> methods, many do not.
Why would tunneling everything though one HTTP method (POST or MPOST) help?
This is what SOAP usually does, right?
> That said, I expect this kludge to go mainstream... though maybe
> by having a
> dedicated SOAP port and straight TCP/IP connections (see the
> comment about
> routers below).
>
> > Doesn't come extensibility (the ability to marshall "anything") with the
> > price of being *harder* to control?
>
> Not necessarily. My bet is that routers will have this capability
> (message
> validation, and smart routing or messages) built into them soon. It's a
> logical extrapolation of the trend in router technology to put
> more layers
> into the box.
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
>
|
