[Council] proposed DAVmech JEP
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?
> 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
> >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
> >>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.
> >Council mailing list
> >Council at jabber.org
> Council mailing list
> Council at jabber.org
Jabber Software Foundation
More information about the Council