[Council] proposed DAVmech JEP

Thomas Muldowney temas at box5.net
Fri Jan 23 11:20:07 CST 2004


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




More information about the Council mailing list