[Council] proposed DAVmech JEP
Matthew A. Miller
linuxwolf at outer-planes.net
Fri Jan 23 11:15:18 CST 2004
I have some serious concerns about this proposed JEP, that I feel need
resolution before actual publication.
My first concern is about SI, and the lack thereof. I see this proposed
JEP talks about using and being compliant with SI in the introduction
and the requirements...and no where else. This is concerning because I
don't see anything here that requires a new SI stream method (e.g. what
exactly does this do, SI-wise, that cannot be done with url-data?).
My second concern is with "x:oob". While I can appreciate the concept
of "offline file transfers", this usage seems especially problematic.
The "x:oob" namespace has previously always been for distributing URL's,
not for transfering files, which has previously always used a different
user interface path than file transfer. There is also no clue anywhere
to differentiate this "x:oob" that this is supposed to be a file
transfer, but yet REQUIRED additional meaning to be attached to the
message (which, in my opinion, does not a clear differentiator make).
These combined mean that there will be backwards-compatibility issues.
The WebDAV aspects of this proposed JEP are intriguing, and I think
those by themselves are worthy of standardizing on, for any HTTP-based
file transfer. Otherwise I don't see anything actually being solved
Peter Saint-Andre wrote:
>Dave Smith and I have written a JEP that details an alternative file
>transfer mechanism, mainly for use when the intended recipient is
>offline, but also helpful if an organization can make use of an existing
>WebDAV deployment. The proposed JEP is here (some work still required
>on Security Considerations and such):
>If you have concerns about publishing this as JEP-0127, please voice
>them on the list.
More information about the Council