headers
Ienup Sung | 1 Nov 2003 02:42
Picon

Re: SASLPrep vs Full Stop code points


Regarding the full stops, while I do understand the point of display vs.
storage/query string in my opinion, I think the issue boils down onto
the followign two things in my view:

1. Should/can we treat ideographic/Asian full stops as equivalent characters
   of the ASCII full stop (U+002E) in 100% of the possible cases/usages?
   The answer is no since the U+002E is not only a full stop character but
   it is also a period and dot/decimal point character; CJK speakers do not use
   the ideographic/Asian full stops as the dot/decimal point character and
   hence some use of the ideographic/Asian full stops rather be preserved as
   they are to be distingushed. And in that cases, can we distinguish what to
   preserve and what not to preserve and map?

2. Should/can we keep the compatiblity with the IDNA's additional and
   pre-processing on the label separators, i.e., mappings of all full stops to
   the U+002E, for the domain style (IDN) names before they are used?
   I think the answer should be yes.

I know the above two sound conflicting and the example shown at the argument
#1 could be considered as a case that may not need to be really supported.
But I thought presenting them might be a valuable thing to do.

With regards,

Ienup
Permalink | Reply | 2 comments |
headers
Kurt D. Zeilenga | 1 Nov 2003 05:52

Re: SASLPrep vs Full Stop code points


At 05:42 PM 10/31/2003, Ienup Sung wrote:
>Regarding the full stops, while I do understand the point of display vs.
>storage/query string in my opinion, I think the issue boils down onto
>the followign two things in my view:
>1. Should/can we treat ideographic/Asian full stops as equivalent characters
>   of the ASCII full stop (U+002E) in 100% of the possible cases/usages?

SASLprep is only applicable to two use cases: simple user names and password.

>   The answer is no since the U+002E is not only a full stop character but
>   it is also a period and dot/decimal point character; CJK speakers do not use
>   the ideographic/Asian full stops as the dot/decimal point character and
>   hence some use of the ideographic/Asian full stops rather be preserved as
>   they are to be distingushed. And in that cases, can we distinguish what to
>   preserve and what not to preserve and map?

SASLprep scope is limited to preparation of user input strings for matching.
Issues such as how to preserving the (unprepared) user input is simply beyond
our scope as matching and hence SASLprep.

>2. Should/can we keep the compatiblity with the IDNA's additional and
>   pre-processing on the label separators, i.e., mappings of all full stops to
>   the U+002E, for the domain style (IDN) names before they are used?
>   I think the answer should be yes.

SASLprep can define one preparation algorithm for simple user names and
passwords.  Simple here implies the input has no structure.  That is,
names have no particular style in respect to the algorithm.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Liqiang(Larry) Zhu | 3 Nov 2003 07:45
Picon
Favicon

Last Call comments: 'The Kerberos Network Authentication Service (V5)'

A minor change:

Section 7.5.1: GSS-CFX is using 22-25, can we update these numbers?

Thanks, Larry

-----Original Message-----
From: owner-ietf-announce <at> ietf.org [mailto:owner-ietf-announce <at> ietf.org]
On Behalf Of The IESG
Sent: Tuesday, October 21, 2003 12:47 PM
To: IETF-Announce 
Cc: ietf-krb-wg <at> anl.gov
Subject: Last Call: 'The Kerberos Network Authentication Service (V5)'
to

         Proposed Standard 
Reply-to: iesg <at> ietf.org

The IESG has received a request from the Kerberos WG WG to consider the 
following document:

- 'The Kerberos Network Authentication Service (V5) '
   <draft-ietf-krb-wg-kerberos-clarifications-04.txt> as a Proposed 
Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg <at> ietf.org or ietf <at> ietf.org mailing lists by 2003-11-04.

The file can be obtained via
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ienup Sung | 3 Nov 2003 20:51
Picon

Re: SASLPrep vs Full Stop code points


I agree that the SASLprep is more suitable and applicable for simple
user names and passwords and if the additional mappings such as the full
stops are needed, they are more suitable and correct to be done at
the outside of any Stringprep/Stringprep profiles and most preferrably before
the application of the Stringprep profile(s). <-- These are also my points
all along.

The reasons are like the following that the U+002E (full stop and dot/decimal
point) isn't the same or equivalent to the ideographic/Asian full stops
all the time; if they were, the Unicode itself would define them as
equivalent forms/characters and show canonical/compatiblity decomposition(s)
at each characters so that the Unicode normalizations would normalize
those characters into a (normalized) character.

Also, if everyone would agree on the fact that the ideopgraphic/Asian
full stops are not equivalent to the U+002E and yet we still need to support
the mappings described in the IDNA for the compatibility/interoperability on
the Internet domain style names (only), then, I'm also thinking that everyone
would agree this conditional mappings should be done outside of the Stringprep
and any of the Stringprep profiles (since the Stringprep itself doesn't
really allow conditional mappings at the mapping step as of today even though
a profile *possibly and maybe* could define such conditional mappings).

Re user provided strings, I have the following example that shouldn't match
as the same thing:

	3.14
	３。１４
	3。14
(Continue reading)

Permalink | Reply | 6 comments |
headers
Michael Thomas | 3 Nov 2003 21:16
X-Face
Picon
Favicon

still no pkinit in the archives


Hi folks,

I really don't understand why pkinit's glacial
progress isn't either

a) in the drafts repository
b) linked from this wg's web page

maybe pkinit has died and nobody's given it a
death certificate?

	Mike
Permalink | Reply | 3 comments |
headers
Brian Tung | 3 Nov 2003 21:59
Picon
Favicon

Re: still no pkinit in the archives

Michael Thomas wrote:
> I really don't understand why pkinit's glacial
> progress isn't either
> 
> a) in the drafts repository
> b) linked from this wg's web page
> 
> maybe pkinit has died and nobody's given it a
> death certificate?

It hasn't died.  I put together a pk-init-17 for review a while ago,
we've had some comments, and I think I'll present on plans in the
Tuesday session.

Brian Tung <brian <at> isi.edu>
Permalink | Reply | 2 comments |
headers
Douglas E. Engert | 3 Nov 2003 22:15
Favicon

[Fwd: BOUNCE ietf-krb-wg <at> achilles.ctd.anl.gov: Non-member submission from [The IESG <iesg-secretary <at> ietf.org>]]


Approved: secret_word
To: IETF-Announce: ;
Cc: ietf-krb-wg <at> anl.gov
From: The IESG <iesg-secretary <at> ietf.org>
Subject: Last Call: 'The Kerberos Network Authentication Service (V5)' to Proposed Standard 
Message-Id: <E1AC3PH-0001Dd-3S <at> asgard.ietf.org>
Sender: Apache <apache <at> asgard.ietf.org>
Date: Tue, 21 Oct 2003 16:47:07 -0400
Reply-to: iesg <at> ietf.org

The IESG has received a request from the Kerberos WG WG to consider the 
following document:

- 'The Kerberos Network Authentication Service (V5) '
   <draft-ietf-krb-wg-kerberos-clarifications-04.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg <at> ietf.org or ietf <at> ietf.org mailing lists by 2003-11-04.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-kerberos-clarifications-04.txt
Permalink | Reply | 0 comments |
headers
Michael Thomas | 3 Nov 2003 22:29
X-Face
Picon
Favicon

Re: still no pkinit in the archives


My exasperation here is that the draft never seems
to be in the archives or linked to by the wg site.
Every time somebody asks me about it I have to
take a wild guess as to what version they should
look at, etc. Can we please get this fixed?

	 Mike

Brian Tung writes:
 > Michael Thomas wrote:
 > > I really don't understand why pkinit's glacial
 > > progress isn't either
 > > 
 > > a) in the drafts repository
 > > b) linked from this wg's web page
 > > 
 > > maybe pkinit has died and nobody's given it a
 > > death certificate?
 > 
 > It hasn't died.  I put together a pk-init-17 for review a while ago,
 > we've had some comments, and I think I'll present on plans in the
 > Tuesday session.
 > 
 > Brian Tung <brian <at> isi.edu>
 >
Permalink | Reply | 1 comment |
headers
Sam Hartman | 4 Nov 2003 20:23
Picon
Favicon

Re: still no pkinit in the archives

>>>>> "Michael" == Michael Thomas <mat <at> cisco.com> writes:

    Michael> My exasperation here is that the draft never seems to be
    Michael> in the archives or linked to by the wg site.  Every time
    Michael> somebody asks me about it I have to take a wild guess as
    Michael> to what version they should look at, etc. Can we please
    Michael> get this fixed?

I do believe that if pkinit is going to make the kind of progress we
talked about in September, it needs an active editor who will keep it
in the archives and moving forward.

I'm not volunteering; I'm happy if pkinit makes much slower progress,
but apparently not everyone falls in this camp.

--Sam
Permalink | Reply | 0 comments |
headers
Sam Hartman | 4 Nov 2003 20:30
Picon
Favicon

Making sure WG clarifications comments are reflected


Since the WG last call there have been a few comments within the WG; I
know we discovered at least one error in September.  Is someone
responsible for making sure these comments get forwarded to the IESG?

Did all the comments even make it to the list here?
Permalink | Reply | 1 comment |

Gmane