[Council] proposed DAVmech JEP

[Matthew A. Miller]

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 
here yet.


-  LW
 
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):
>
>http://www.jabber.org/~stpeter/editor/davmech.html
>
>If you have concerns about publishing this as JEP-0127, please voice
>them on the list.
>
>Thanks.
>
>Peter
>
>  
>