I support publication of draft-ietf-sasl-scram.
I have implemented SCRAM in a beta version of GNU SASL [1], see [2], so
I have good confidence that the document is in sufficiently good
technical condition.
I have not yet managed to do interop testing with anyone else though.
Please contact me if
Simon Josefsson wrote:
I support publication of draft-ietf-sasl-scram.
I have implemented SCRAM in a beta version of GNU SASL [1], see [2], so
I have good confidence that the document is in sufficiently good
technical condition.
I have not yet managed to do interop testing with anyone else
--On Tuesday, September 15, 2009 10:55 +0200 Simon Josefsson
si...@josefsson.org wrote:
...
2) This is a technical issue.
SCRAM does not say anything about the encoding used for the
password (e.g., Latin-1, UTF-8) or whether SASLprep should be
applied to the string or not. I believe this
On Sep 15, 2009, at 2:41 PM, John C Klensin wrote:
--On Tuesday, September 15, 2009 10:55 +0200 Simon Josefsson
si...@josefsson.org wrote:
Personally, in
the long term I would prefer to deprecate SASLprep in favor of
Net-UTF-8 (i.e., RFC 5198) for use in SASL applications. I
believe
John C Klensin john-i...@jck.com writes:
For highest interoperability the document could do MUST use
UTF-8 and MUST use SASLprep. I understand that some people
will not implement SASLprep, and I agree with them that there
are valid reasons for not implementing SASLprep (such as it
being
Simon Josefsson wrote:
John C Klensin john-i...@jck.com writes:
[...]
Because of the unrestricted UTF-8 problem, and without taking a
position on deprecating SASLprep, my inclination would be to
strengthen Simon's proposed requirement a bit to MUST use UTF-8
and SHOULD use SASLprep or at
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 9/15/09 9:37 AM, Simon Josefsson wrote:
John C Klensin john-i...@jck.com writes:
For highest interoperability the document could do MUST use
UTF-8 and MUST use SASLprep. I understand that some people
will not implement SASLprep, and I agree
Hi Ben,
I am fine with your proposed text.
Many thanks for your review and comments.
Regards,
Ahmad
-Original Message-
From: Ben Campbell [mailto:b...@estacado.net]
Sent: Monday, September 14, 2009 2:02 PM
To: Muhanna, Ahmad (RICH1:2H10)
Cc: Khalil, Mohamed (RICH2:2S20);
I support publication of draft-ietf-sasl-scram.
Nico
--
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Kurt,
Just for clarification... I fear that parts of this note are
going to be a mini-tutorial on some Unicode subtleties, but one
can't understand this without them and I suspect some interested
readers don't have that level of understanding.
--On Tuesday, September 15, 2009 15:28 +0100 Kurt
Hi.
The Unicode/ SASLprep discussion in a different thread
notwithstanding, I favor approval of this document.
However, as an editorial matter, Appendix A points to two
expired I-Ds, draft-ietf-sasl-digest-to-historic and
draft-ietf-sasl-crammd5-to-historic. Expired I-Ds are
notoriously hard
I¹m looking for direct comments on an updated document, Recommendations for
the Remediation of Bots in ISP Networks, available at
http://tools.ietf.org/html/draft-oreirdan-mody-bot-remediation-03.
I¹m asking here as this doesn¹t really fit neatly into any existing WGs.
(Though we¹ll be posting
--On Tuesday, September 15, 2009 12:16:44 PM -0400 John C Klensin
john-i...@jck.com wrote:
I really don't think (3) is a good idea, but an unqualified
MUST ... UTF8, SHOULD SASLprep
strikes me as a terrible idea simply because the same character,
coded in different ways through no fault of
--On Tuesday, September 15, 2009 02:55:54 PM -0500 Nicolas Williams
nicolas.willi...@sun.com wrote:
I think the right answer is to leave _query_ strings unnormalized and
require that _storage_ strings be normalized (see my separate reply on
that general topic, with a different Subject:, just
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document:
--On Tuesday, September 15, 2009 14:43 -0500 Nicolas Williams
nicolas.willi...@sun.com wrote:
...
[OT for the draft-ietf-sasl-scram thread, but possibly of
interest to the IETF list.]
NFSv4 left normalization form unspecified for filenames. We
ended up implementing
The Security Issues in Network Event Logging (syslog) working group in the
Security Area of the IETF has been rechartered. For additional
information, please contact the Area Directors or the working group
Chairs.
Security Issues in Network Event Logging (syslog)
A modified charter has been submitted for the Network Endpoint Assessment
(nea) working group in the Security Area of the IETF. The IESG has not
made any determination as yet. The modified charter is provided below for
informational purposes only. Please send your comments to the IESG
mailing
A modified charter has been submitted for the IP Flow Information Export
(ipfix) working group in the Operations and Management Area of the IETF.
The IESG has not made any determination as yet. The modified charter is
provided below for informational purposes only. Please send your comments
to
A new IETF working group has been proposed in the Applications Area. The
IESG has not made any determination as yet. The following draft charter
was submitted, and is provided for informational purposes only. Please
send your comments to the IESG mailing list (i...@ietf.org) by Tuesday,
A new IETF working group has been formed in the Real-time Applications and
Infrastructure Area. For additional information, please contact the Area
Directors or the WG Chairs.
SIP Common Log Format (sipclf)
--
Last Modified: 2009-09-15
Additional information is
21 matches
Mail list logo
