[JDEV] Proposals (file transfers and info/query)

[Jeremie]

>    Under <type>***</type>: •private >>Priavte<< only data
> 
>    Immediately before discussion: "By simply changing the <query> to 
> a <set>, the data can be updated/stored. (This would of course only 
> be allowed by an authenticated session from the correct user 
> account)" -- It's my understanding that the grammatically correct way 
> would be to remove the period from its current location and place it 
> after the final parenthesis.

Corrected...

> 
>    Now, to the potentially more interesting parts...
> 
> [snipped excellent discussion of discoverable queries]

This ran through my head some time ago but I forgot to include it in the
proposal... What I was thinking is that when an empty query was sent, a
reply of all of the possible fields would be returned:

<info>
	<to>jer</to>
	<target>user</target>
	<type>public</type>
	<query/>
</info>

Would be the "discovering" query, with a possible reply of:

<info>
	<to>jer</to>
	<target>client</target>
	<type>public</type>
	<result><name/><email/><zip/></result>
</info>

Unless there is an issue with this, I'll add it to the proposal :)

For automated purposes though, I would still like to come to a consensus
on a standard set of queries for different purposes.  So that for instance
clients could have a special "about" box for the server that would show
the common variables(url, admin name/email, etc), and those simple queries
would need to be hard-written into the client.

> > File Transfer Proposal: http://core.jabber.org/file.html
> 
>    Under HTTP: "Why not utilize all that has been invested in 
> knowledge and development in HTTP for file transfers with Jabber?" 
> That should be "of" HTTP, not "in" HTTP.
> 
>    Under How?: It's not as simple as just saying "Ok, we'll use 
> HTTP". -- I believe the final " goes after the period. As for "the 
> URL could be placed somewhere else in the message(possibly in the ext 
> tags?).", I think you've been programming too much -- There's 
> normally a space before a parenthesis.
> 
>    Under Sending Files: The same parenthsis-w/o-space problem occurrs 
> several times in the last paragraph.

Fixed, gracias!

>    Hrm I think allowing a description and address is definately a 
> good idea. Requiring client parsing of say seems like a bad idea, as 
> does including the URL in <ext> because, if I understand right, 
> unrecognized content in <ext> wouldn't normally be shown to the user. 
> Not sure what's a good idea, though...

Why not use the subject field then, the <sub>http://whatever</sub> would
be the "subject" of the message and the <say></say> would contain the
description.  This way with clients that don't recognize the special
message, their users can still access and cut/paste the URL.  This also
works well with transports to other IM services, who would all preserve
the subject even if they don't support the message type directly.

>    Though this is designed for file transfer, I think it would work 
> fine for negotiating *any* client-client connection. You might want 
> to call it type=ctc (client to client) or something similar though, 
> rather than "file" which could be confusing to developers and cause 
> client-writers to create their own CTCP when they don't realize that 
> "file" covers almost every other possible type of client-client 
> connection, too.

Agreed.  What about type='url'?  This way any resources that can be
described via a URL (which is just about everything anymore and custom
uses can be of the format custom://server:port/resource) can be sent.

>    I corrected the errors I saw, but didn't do a careful proof-
> reading. As far as the ideas behind the proposals, though, they both 
> seem quite sound and no real problems come to my mind, just the 
> couple minor suggestions mentioned above.

Thanks!  Comments and corrections appreciated!

Jer