[Council] JEP-20 Comments

Mike Lin mikelin at MIT.EDU
Thu Jul 18 17:22:12 CDT 2002


I think the larger objection I have is that the features are specified
as a rudimentary flat string. Joe points out that for version numbers,
you could simply add it to the string; but as soon as you have
additional attributes to specify, are you then supposed to permute over
all combinations?

IMHO, this is a context in which the use of a more structured system for
describing features is warranted.

-Mike

On Thu, 2002-07-18 at 16:53, Peter Saint-Andre wrote:
> There was a last call and the only comment was something about browse and
> disco, not feature negotiation (unless he intended to say that feature
> negotation should be done in the context of a service discovery protocol
> like browse or disco, which is just plain wrong). The JEP Editor took the
> silence of the list to imply a lack of objections and moved ahead to a
> vote. Last call means last call. If people had objections at that point,
> they should've piped up.
> 
> That said, I don't take -1 votes personally and it just means the concerns
> need to be addressed by the JEP author. So far several concerns have been
> raised:
> 
> 1. Mention of security negotation in paragraph 2 of section 1. As Joe has
> pointed out, this paragraph can be removed with no appreciable impact on
> the substance of the proposal. I move that we remove this paragraph.
> 
> 2. The proposed protocol would not work to negotiate networking or 
> connection to a server, such as that described in the email Matthias sent
> to Standards-JIG. However, the proposed protocol is explicitly designed
> for negotiation of features between two network endpoints (i.e., two
> clients). Matthias even wrote as follows:
> 
>    I havn't thought about the usage of JEP-0020 because 
>    I only thought of JEP-0020 as a protocol to negotiate 
>    features between clients (or maybe between clients 
>    and servers). But it's true, it has to be thought 
>    about if this protocol can be used at the 
>    networking/connection layer too.
> 
> Note the word "if". This statement is hypothetical. The protocol is not
> designed to be used for the things being described here. If desired, the
> JEP author can be asked to add text that explicitly forbids the use of
> this protocol for *anything* except the negotiation of features between
> two clients.
> 
> 3. I get the sense that perhaps more examples would be helpful.
> 
> These are the only concerns I have seen in this thread. Please email the
> list if you know about more.
> 
> Thanks!
> 
> Peter
> 
> --
> Peter Saint-Andre
> Jabber Software Foundation
> http://www.jabber.org/people/stpeter.html
> 
> On 18 Jul 2002, Thomas Muldowney wrote:
> 
> > I'm really really confused how this JEP got to a vote.  I really just
> > learned yesterday, at the 07-17 JSF meeting, that the JEP was in vote,
> > and I decided to go back and read all of the associated emails to see
> > what I was missing.  I found a whole thread of pretty much people
> > suggesting other methods, syntaxes, and what not for enhancing
> > JEP-0020.  Then i found a last call thread, there was one reply, even
> > there it said that it still needed more review to be pushed forward.  No
> > reply to that about it going to vote.  Yet, here we are.  Even now,
> > based on Matthias' comments we're finding things that could be changed. 
> > Why and How is this JEP ready for vote?  I'd like to bring up these
> > issues without putting in my own feelings on the JEP, so that I can
> > better understand the process used on the JEP.  If you want my actual
> > feelings, just ask and I'll mail them in.
> > 
> > --temas
> > 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Council mailing list
> > Council at jabber.org
> > http://mailman.jabber.org/listinfo/council
> > 
> 
> _______________________________________________
> Council mailing list
> Council at jabber.org
> http://mailman.jabber.org/listinfo/council





More information about the Council mailing list