[Council] proposed DAVmech JEP

Peter Saint-Andre stpeter at jabber.org
Mon Feb 23 18:37:44 CST 2004

OK, I cleaned this up a bit. A few points:

1. This is not a stream initiation profile, and I've removed references
to stream initiation. The main point of this JEP is doing a file
transfer while the recipient is offline, so it's not SI.

2. Using WebDAV leads to a secondary use case: the ability to use
existing WebDAV infrastructure for file transfer, for example, in
organizations that require a file to be put onto a WebDAV server and
virus-checked there before being delivered to the recipient(s). It's
possible to do this with JEP-0065 (have the proxy put the file to WebDAV
for checking, or virus-check it on its own), but it seems more
straightforward to have that built in.



On Fri, Jan 23, 2004 at 11:20:07AM -0600, Thomas Muldowney wrote:
> I talked with Diz this morning, and this is very much the same feelings 
> I was expressing to him.
> SI is a large concern to me.  We spent all this time to figure out a 
> common startup mechanism to make other methods easier, and it's 
> partially ignored here.  I need more commentary explaining where it is 
> or is not used and why.
> x:oob is another large concern.  As far as I know, most clients treat 
> x:oob as an attachment.  Just a clickable link that uses the registered 
> url handler to open it.  If that's the case, what's the point of the 
> extra info?  Most clients will just disregard it.
> Maybe this needs some wiki time to flush it out a bit more?
> --temas
> On Jan 23, 2004, at 11:15 AM, Matthew A. Miller wrote:
> >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
> >>
> >>
> >
> >_______________________________________________
> >Council mailing list
> >Council at jabber.org
> >http://mailman.jabber.org/listinfo/council
> _______________________________________________
> Council mailing list
> Council at jabber.org
> http://mailman.jabber.org/listinfo/council

Peter Saint-Andre
Jabber Software Foundation

More information about the Council mailing list