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

Scott Robinson scott at tranzoa.com
Tue Aug 10 12:42:55 CDT 1999


Interleaved response.

Scott.

* Jeremie translated into ASCII [Tue, Aug 10, 1999 at 08:29:19AM -0500][<Pine.LNX.4.10.9908100807420.21027-100000 at lor.jeremie.com>]
> > In a previous message your said your FTP proposal would handle the MIME
> > situation. I don't see that is has; however, before I end up posting my MIME
> > 6 page essay I'm asking the question if there is to be more posted soon on
> > the subject? I wouldn't want to post duplicated information.
> 
> What specific MIME functionality is lacking that cannot be expressed via
> normal HTTP/1.1 headers?  The proposal simply suggests that Jabber needn't
> know anything internally about the resources being described by an HTTP
> URL besides the URL itself, and that all other information about that
> resource can be gathered via an HTTP HEAD request to the resource.
> 

Are you impling that instead of encoding our messages in MIME, that we
encode them with some HTTP headers on the top? I'm going to assume not.

What functionality is left out is the case if I want my message to be in
HTML. Negotiating a transport for something like that would be crazy when I
could just place Content-Type: text/html in the MIME encoded Jabber message.

> > A comment on Info/Query: You take the position that you don't want to waste
> > the brain/manhours spend on currently existing protocols. I would like to
> > place forward the suggestion that we create a Info/Query system very similar
> > to LDAP, if not a direct mapping to Jabber's XML based protocol.
> 
[snap]
> usefullness.  The info/query proposal isn't just for setting/querying user
> information, but for also querying internal server data or setting
> administrative variables.  For example, there might be a query to a Jabber
[snap]
> 
> Also, another VERY powerful aspect of the Info/Query proposal is the
> client to client queries, where one client can send a query to another
> client (it's ignored by the server and just passed on.).  This is what
[snap]
> 
> I realize that there is overlap between the user information aspect of the
> Info/Query proposal and existing LDAP functionality, but IMHO there is
> lots of additional value in the proposal for other purposes.  As I've
> mentioned before, if we just keep the client->server queries in the XML
> stream, the server can(and will) have a mod_ldap that utilizes an LDAP
> server in the background to manage the user information.  And of course,
> this LDAP server should be queryable directly via LDAP for those that want
> to access it directly.
> 

I don't see how LDAP mapped to our XML system would in anyway limit the
usefulness of the info/query protocol. The examples you have given are
wrapped into the LDAP idea almost the same way they're wrapped into the
current Info/Query protocol.

I'm not suggesting USING LDAP, but instead wrapping its spec into our XML
stream ala MIME in Jabber.

> Does this make sense, or am I flogging the wrong issue?
> 

I think I haven't been typing clearly for everyone. You seem to be doing
just fine. ;)

> Jer
> 
> 
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev




More information about the JDev mailing list