[standards-jig] Call for Experience: JEP-0078 (Non-SASL Authentication)

JD Conley jconley at winfessor.com
Wed Sep 22 17:03:12 UTC 2004

I have a few comments. . .

Section 2:  The list should tell you what kind of digest up front:
1. plaintext
2. digest (SHA1)


Section 3.1: "If there is no such username, the server SHOULD NOT return
an error" ... 

I agree.  But why even leave the username in the get request?  It is
completely unnecessary.  I know there are a lot of applications out
there that require the element (some I have written, included), but it
is unnecessary and should be removed if this JEP is progressing to


Section 3.1 Example 7: points should be capitalized and end with

Section 3.1 Example 7, #2: Saying "... note that ..." isn't strong
enough.  How about:
There is a resource conflict (there is already an active session with
that resource identifier associated with the same username). The
RECOMMENDED behavior is for the server to terminate the existing session
and create the new one.  The server MAY provide the opposite behavior if
desired, leading to a conflict error for the newly requested login.


Section 4 reads "Upon receiving a stream header qualified by the
'jabber:client' namespace, a server that returns stream features MUST
also announce support for non-SASL authentication by including the
relevant stream feature whenever it also sends SASL authentication
features that are safe over TLS or SSL (e.g., SASL PLAIN)."

Saying "features that are safe over TLS or SSL" isn't quite correct.  An
implementation could allow PLAIN over an unsecured channel
(unfortunately it does happen in the real world).  An implementation may
also support non-sasl digest and not plaintext.  In which case the
credentials are safe to travel an unsecured channel.


Section 6
Paragraph 1, third sentence: This should be in the protocol flow
somewhere and include an example, not just in security considerations (I
didn't notice that error case until now).

Paragraph 3: Isn't this redundant to Paragraph 1, first sentence?  Also,
it should read that "...this JEP will be deprecated..."  Might as well
get rid of this one asap.

Paragraph 4: See my comments on Section 4, above.


> -----Original Message-----
> From: Peter Saint-Andre [mailto:stpeter at jabber.org]
> Sent: Wednesday, September 22, 2004 9:21 AM
> To: standards-jig at jabber.org
> Cc: jdev at jabber.org
> Subject: [jdev] Call for Experience: JEP-0078 (Non-SASL
> On behalf of the Jabber Council, I hereby issue a Call for Experience
> on JEP-0078
> (Non-SASL Authentication). As defined in JEP-0001, the Call for
> Experience is the last chance to provide feedback on a JEP before it
> advances from Draft to Final. To help the Jabber Council decide
> this JEP is ready to advance to a status of Final, the JSF would like
> to gather the following information:
> 1. Have implementers experienced any problems with the protocol as
> defined in this JEP? If so, please describe the problems and, if
> possible, suggested solutions.
> 2. Is the text of this JEP clear and unambiguous? Are more examples
> necessary? Is the conformance language (MAY/SHOULD/MUST) appropriate?
> Have implementers found the text confusing at all? Please describe any
> suggestions you have for improving the text.
> If you have any comments on this JEP, please provide them within the
> next 3 weeks (i.e., by October 13), at which time the Call for
> Experience will end. After the Call for Experience, this JEP will if
> necessary undergo one more revision, after which it will be presented
> to the Jabber Council for voting to a status of Final.
> You may review the JEP here:
> http://www.jabber.org/jeps/jep-0078.html
> Please send all feedback to <standards-jig at jabber.org>.
> Thank you.
> Peter
> --
> Peter Saint-Andre
> Jabber Software Foundation
> http://www.jabber.org/people/stpeter.php
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mail.jabber.org/mailman/listinfo/jdev

More information about the Standards mailing list