No subject


Fri Jul 9 09:46:20 CDT 2004


> Revision History
> Version 1.1 (2002-05-22)
> Changed examples. (pgm)

So, nearly 2 months ago, any "references to security and 
encryption" were removed.

Excerpts from Matthias' comments:

> - To whom do I have to address the <iq/>s? The http
> polling server has no JID.

this is unrelated to the feature negotiation protocol.  
whatever protocol we pick would have this problem.

> - When we do the negotiation there is no Jabber connection
> yet.  We would have to put the requests in a pseudo Jabber
> connection that is just used for feature negotiation.

yep.  same as above.  there *can be* no jabber connection
at this point, since you're trying to figure out how
to connect.

> - If the client sends the <iq/> the server will decide
> witch features are used, what we discussed until now was
> that the client decides.

The client should probably decide, since the client has a
chance of knowing something about the network it is running
on.

> - The server could not choose more then one feature, we
> would have to send a request for each type of feature (one
> of authentication methods, one for session tracking
> methods, ...)

huh?  the JEP says "containing one or more <feature>
elements".  Yes, there might need to be an example that
shows what happens with multiple features, but it is clearly
the intent of the author that it be possible to do this.

> - With JEP-0020 we can't use one polling server to connect
> to different Jabber servers.

I question the value of this, but that's just me.  I think
if you want to provide polling services, you should run your
own polling server, since the network load associated with
polling is so harsh.

> There is now way the server could tell to which hosts he
> allows to connect to.  There is nothing like a <param/>
> tag for the <option/> tag.

This is an interesting idea.

How about (note: slightly contrived example):

<feature>
  <option name="webdav">
    <param name="url">http://some.webdav.server/</param>
  </option>
</feature>

> One general thing to JEP-0020: I'm missing something like
> a version attribute to the options. E.g. for "webdav"
> that's used as an example it would be interesting to know
> which versions of webdav are supported/which one is
> selected.

I assert that there exists a solution to this, which is to
use webdav-1.0 as the option name.  You could then just send
a separate option for each of the different flavors you
support.  That being said, if a people feel really strongly
about this, I wouldn't oppose it.  I just don't think it
will be used that much.

On the topic of how to discover connection types, Jer and I
were discussing the possibility of using an XML file at
http://www.host/jabber.xml that contains all of the
connection parameters.  DNS SRV could also be used, but most
client OS's still don't supply adequate APIs for doing SRV.
Also, the people that control the DNS records are probably
the same people that control the firewall.  You'd probably
not want to involve them if you didn't have to, since if you
could get them involved you might not need anything more
than the protocol already provides.

What I'm getting at is that just because JEP-0020 is not the
right approach for solving this particular problem does not
mean it it not the right approach for the problems it is
actually trying to solve.

-- 
Joe Hildebrand

> -----Original Message-----
> From: Mike Lin [mailto:mikelin at MIT.EDU]
> Sent: Wednesday, July 17, 2002 9:43 PM
> To: council at jabber.org
> Subject: [Council] JEP-0020
> 
> 
> Good evening,
> 
> I never voted on JEP-0020 because I assumed it would never go through
> anyway. To my own suprise, I must now vote -1.
> 
> I've spoken with a number of people besides myself who for various
> reasons really feel this protocol is inappropriate for 
> standards track,
> particularly its references to security and encryption which 
> are highly
> questionable. Furthermore, I asked Matthias Wimmer to investigate the
> possibility of using JEP-0020 syntax for HTTP polling 
> negotiation, which
> while technically outside the rest of the Jabber protocol should be a
> fairly straightforward negotiation, and he pointed out a number of
> issues. His comments are at: 
> 
> http://mailman.jabber.org/pipermail/standards-jig/2002-June/00
1013.html

My understanding is that certain other people with more credibility than
me are supposed to chime in at this point on why JEP-0020 should be done
differently, so that I don't look too bad.

Love,
Mike

_______________________________________________
Council mailing list
Council at jabber.org
http://mailman.jabber.org/listinfo/council



More information about the Council mailing list