Subject: Re: DNS SRV for Kerberos

From: Jeffrey Altman <[email-masked]>
Date: Wed, 10 Nov 99 0:16:27 EST

> > >You borrowed its method for the draft's TXT record search
> > >procedure, but added an extra level of indirection that gets the
> > >design in trouble.
> >
> > Explain, please?
> 
> When determining what realm an unconfigured Kerberos client is in, the
> Cygnus procedure just added "kerberos." to the front of the domain
> name, then started dropping prefixes until it found an A record for
> that name.  The realm name was the same as the domain suffix (if you
> are on foo.cygnus.com and don't find kerberos.foo.cygnus.com, you try
> kerberos.cygnus.com, find it, and your realm is "CYGNUS.COM" and your
> master server is kerberos.cygnus.com).
> 
> If you follow the same procedure, but looking for a TXT record, the
> contents of the TXT record could point you anywhere in the name space
> as the realm name.  It could say `_kerberos.cygnus.com TXT
> "OUR-FAVORITE-REALM"'.  This realm name cannot be looked up in the DNS
> to find the master server, though the code will try.
> 
> Furthermore, three Kerberos realms such as "MIT.EDU", "mit.edu", and
> "Mit.EdU" are distinct and independent realms in case-sensitive
> Kerberos, but these all map to the same domain name.  There is no way
> for the DNS to represent different SRV records for these three different
> realms.  The draft doesn't even notice this problem, let alone address
> it, because it's perpetually confused about the name spaces.

Actually, we know about this problem and it is already addressed in
the next revision.  If you had been at the CAT WG meeting you could
have been there for the discussion.

The idea is that this draft is only to be used with Realm Names that
are valid domain names.  But that does not mean that a Domain and and
Realm are the same thing.

[cygnus hack deleted]

> Here's a suggestion.  What's wrong with making the realm name be a
> suffix of the domain name?
> 
> Keeping the realm name-space and the domain name-space separate
> provides some sort of flexibility, but as far as i know nobody needs
> that flexibility, and it ties attempts to do simple DNS integration
> into knots.  You mention complex environments, and indeed two or three
> of those might have to either rename their realms, rename their hosts,
> and/or add some cross-certification keys, if they wanted to use your
> new proposed protocol -- but isn't that the only cost of unifying the
> name spaces?  It's not like Kerberos is wildly popular and hundreds of
> thousands of sites would have to change.  Nor would this affect people
> running old code and old protocols with config files, which would
> continue to work.

First of all, I know of several sites that have a single domain with
multiple realms of control.  I know of sites that have a single realm
for multiple domains.  This becomes even more common when you have
satellite sites that are on DSL or Cable modem lines that are part of
the same Realm as the primary site.

As for the hundreds of thousands.  There may not be hundreds of
thousands of Realms, we do not know.  But there are clearly millions
of computers.  I would not like to be the one responsible for updating
all of them.

> Declaring a simple rule that realm names and domain names *are* the
> same name space would eliminate whole piles of confusion -- not just
> in the code, but in the minds of users and administrators.  (Cygnus
> documentation recommended making them the same, except making the realm
> name be upper case to appease the gods.  But then the rest of the doc
> had to explain whether each name in each context was a realm or a domain name.)
> 
> The draft perpetuates the separation of name spaces, by having a
> record that points from one namespace to the other.  It then compounds
> the confusion by attempting to look up one sort of name in the opposite
> name space!  A mere statement that "this only works for people who
> pick the same domain name and realm name" is insufficient to paper
> over the philosophical problem.  What *is* a realm name, and why
> should it be *different* from a domain name?  The community has failed
> to answer that with anything more than argument from authority.

There is no requirement in our draft that the Realm Name and the
Domain name be equal.  They don't even have to have the same root.
The only requirement is that the Realm name contain a suffix which is
a valid Domain Name allocated to the organization.  There is no
requirement that machines that belong to that realm have the same
suffix.

For instance

  KERBEROS-TEST.COLUMBIA.EDU

is a valid realm name belonging to Columbia.Edu.  However, the
machines that are in this realm have hostnames as diverse as

  xx.kermit.columbia.edu
  xx.cc.columbia.edu
  xx.tc.edu
  xx.barnard.edu
  xx.redconnect.edu
  ...

These machines are in separate domains but they use a common Realm for
authentication purposes.  The servers that are a part of the Realm may
or may not be in the same domain.

There are other locations that use multiple realms for a single domain
or even have overlapping realms for the same machines depending on
service being accessed.

A realm name is an collection of hosts which share a common
authentication service with a single source of administration.

    Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
                 The Kermit Project * Columbia University
              612 West 115th St #716 * New York, NY * 10025
  http://www.kermit-project.org/k95.html * [email-masked]

---

From: Paul A Vixie <[email-masked]>
Date: Thu, 11 Nov 1999 09:37:43 -0800

>> Kerberos, but these all map to the same domain name.

yes.  as i said, kerberos and dns use different character sets.

>>                                                      There is no way
>> realms.

oh, feh.  please read [RFC1034 3.3] before making such statements again.

---

From: John Gilmore <[email-masked]>
Date: Thu, 11 Nov 1999 22:07:02 -0800

> oh, feh.  please read [RFC1034 3.3] before making such statements again.

OK, I just read it.  I stand corrected.  The DNS could represent those
three SRV records as different DNS records, if an encoding for case in
the labels was devised.  The draft I was reviewing did not propose any
such encoding; are you suggesting that it should?

	John

---

From: Paul A Vixie <[email-masked]>
Date: Fri, 12 Nov 1999 00:03:41 -0800

> such encoding; are you suggesting that it should?

yes, i think it should.

actually, i think kerberos realm names ought not be case sensitive, but
nobody on namedroppers cares what i think about how kerberos ought to work,
so given that this conversation only has a dns context, i think that the
realm names ought to be mapped into unambiguous dns names.  utf-8 anybody?

note that this will impact win2000, which went ahead and used SRV for
kerberos well in advance of the draft we're here debating.  (which i'm
not slamming them for -- per-service RFC's for each use of SRV was never
something we expected... but still there's this character set issue.)

---

From: Paul A Vixie <[email-masked]>
Date: Wed, 17 Nov 1999 10:18:43 -0800

> The DNS itself is OK with binary data, [...]

no, it's not.  it treats 0x41 as identical to 0x61, for example,
and there is no way to escape this special treatment with any 
sort of lead-in or escape character.  if that octet appears in
the middle of (for example) an iso10646 name (or any other octet
in the ranges 0x41..0x5A and 0x61..0x7A) then DNS will mistreat
it.

> > ...
>
> I assume by this you mean that Windows 2000 has
> restricted the alphabet for realm names to all upper
> case, and/or has declared them the same as domain
> names?  Is this documented anywhere?  This would be
> important to SAMBA and other code...

i don't know how they're doing it.  but they're using SRV for KRB5.

---

From: Terry Lambert <[email-masked]>
Date: Wed, 17 Nov 1999 09:47:18 -0800

Paul A Vixie wrote:
> 
> > OK, I just read it.  I stand corrected.  The DNS could
> > represent those three SRV records as different DNS
> > records, if an encoding for case in the labels was
> > devised.  The draft I was reviewing did not propose
> > any such encoding; are you suggesting that it should?
> 
> yes, i think it should.
> 
> actually, i think kerberos realm names ought not be
> case sensitive, but nobody on namedroppers cares what
> i think about how kerberos ought to work, so given
> that this conversation only has a dns context, i think
> that the realm names ought to be mapped into unambiguous
> dns names.  utf-8 anybody?

I rather hesitate to suggest this, but...

UTF-8 is not a case insensitive coding, and so for case
insensitive storage, it's rather useless.

The DNS itself is OK with binary data, and I'd be
perfectly happy with Unicode (or code page 0 of ISO
10646, if you'd prefer): a 16 bit encoding using the
byte order indicator as a sequence introducer, which
would unambiguously signal both Unicode data, and
the byte order.

Barring that, if we are to put the "backward" in
"backward compatability" (until SRV is a full standard,
I see no need for such compatability, and it can be
standardardized however is desired, without legacy
cruft attached to it)... I think that UTF-5 is
probably the correct encoding choice to fit the
characters into the DNS alphabet.

After saying that, I also have to say: "bletch".

> note that this will impact win2000, which went
> ahead and used SRV for kerberos well in advance of
> the draft we're here debating.  (which i'm not
> slamming them for -- per-service RFC's for each
> use of SRV was never something we expected... but
> still there's this character set issue.)

-- Terry Lambert
-- Whistle Communications, Inc., an I.B.M. Company
-- [email-masked]
-------------------------------------------------------------------
This is formal notice under California Assembly Bill 1629, enacted
9/26/98 that any UCE sent to my email address will be billed $50
per incident to the legally allowed maximum of $25,000.

---

From: "Martin J. Duerst" <[email-masked]>
Date: Thu, 18 Nov 1999 12:51:17 +0900

> insensitive storage, it's rather useless.

Below, you suggest UCS2 or UTF-5, which are also
case-sensitive, and therefore, following your logic,
rather useless. Or did I miss something?

> 10646, if you'd prefer): a 16 bit encoding

As of V2.0, published in 1996, Unicode is equivalent
to the UTF-16 encoding of ISO 10646, and includes, in
theory and soon in practice, characters in plane
(what you call code page) 0-16.

> using the

Using the byte order mark to indicate Unicode may
be an idea. Having more than one byte, or more
precisely, more than big-endian, in the DNS is
a bad idea.

Regards,   Martin.

#-#-#  Martin J. Du"rst, World Wide Web Consortium
#-#-#  mailto:[email-masked]   http://www.w3.org

---

From: Terry Lambert <[email-masked]>
Date: Wed, 17 Nov 1999 15:56:55 -0800

> in the ranges 0x41..0x5A and 0x61..0x7A) then DNS will mistreat

Case folding is historical cruft, and doesn't need to be
applied uniformly to new records stored in the DNS database,
so long as those records are not covered by existing RFC.

My point was that you could say:

	"For SRV records, DNS does not behave that way,
	 since behaving that way is bogus historical cruft,
	 and we hates it, my precious."

and avoid the whole UTF-5 firefight (e.g. "if you are
going to increase the alphabet, then you should allow us
to use non-English names as well as just turning off
case folding").

> i don't know how they're doing it.  but they're using SRV for KRB5.

Crap.  Anyone have any information on this, or will I
have to sic Jeremy Allison on Microsoft?  I haven't
seen this anywhere before Paul's mention of it.

-- Terry Lambert

---

From: Paul A Vixie <[email-masked]>
Date: Wed, 17 Nov 1999 16:05:02 -0800

> so long as those records are not covered by existing RFC.

yes, it does have to be applied uniformly.  it's an attribute of wire
encoding of names and does not depend on where those names appear.

---

From: Terry Lambert <[email-masked]>
Date: Fri, 19 Nov 1999 09:38:41 -0800

> encoding of names and does not depend on where those names appear.

Are SRV records names?  Or can a portion of them be defined
to _not_ be names?  SRV is only draft at this point, not
standard; I think you could argue for a loose interpretation
here.

Even if you can't, UTF-5 (James Seng's proposal for iDNS, I
believe) avoids the issue by encoding all data in a restricted
alphabet that does not include lower case.  I dislike the idea
for iDNS immensely, but the UTF-5 encoding does have some
application where the wire alphabet is very small.

Since SRV is not set in stome yet, one could specify that
the name portion _must_ be interpreted as a UTF-5 encoded
value, instead of literally.  This would allow the data to
pass the case folding unaltered.  For data that is case
sensitive on storage, case insensitive on lookup, one could
make the (ugly, IMO) rule "receiver folds before decoding".

Ideally, the Kerberos guys would 'fix' their case sensitivity
(admittedly for a strange in their eyes definition of 'fix'),
but that doesn't seem likely to happen.  The tendency is
toward inclusion of multilingual data, not toward increased
exclusion of normal ASCII data.

For data that falls outside the DNS wire alphabet, I think
that an exception is going to have to be made somewhere,
unless...

Can anyone tely me why the Kerberos lookup can't return
all of the upper and lower case records, as if a wildcard
lookup had taken place, and then apply a "receiver winnows
responses to find matches" rule?

-- Terry Lambert

---

From: Terry Lambert <[email-masked]>
Date: Fri, 19 Nov 1999 09:55:36 -0800

Martin J. Duerst wrote:
> Terry Lambert wrote:

Yes.  James Seng's draft on UTF-5.  From the namedroppers
list archives:

On Wed, 28 Jul 1999 18:29:19 -0700, James Seng writes:
| UTF-5 is a new proposal, which of course means no vendors
| is going to support it at the moment. However, it has a
| elegance in that the final Unicode strings is within a
| limited A-V,0-9 character set which means it should not
| break any existing DNS client/server. In fact, if you
| go beyond DNS, I doubt it will break any other existing
| client/server for other protocols. This makes it extremely
| compatible UTF.

In other words, a 32 character alphabet (2^5 = 32 is
whre the '5' comes from, I'm guessing).

James initially suggested this for wedging Unicode data
into the standard DNS, and then created a reference
implemetnation to demonstrate it.

The point of this exercise was to support legacy code
that expected DNS data to be in a restricted alphabet.

My personal suggestion on this was that iDNS should use
Unicode data over the wire, with the byte order characters
to indicate, by virtue of the first character's high bit
being set, "here comes Unicode data", and the characters
themselves indicating byte order (Unicode specifies that
Motorolla byte order be used, but Microsoft has largely
ignored this because of Intel-centrism, so we must deal
with it).

Support for legacy applications would then be placed not
in the originating DNS, but in the resolver on the legacy
system, which could do the UTF-5 conversion on behalf of
the application, and could even do so conditionally (perhaps
round-tripping via a leading "-", which registries do not
allow, though valid, or a leading "_").

> (what you call code page) 0-16.

ISO 10646 is 32 bits.  I rolled the entire upper 32 bits
(the upper 16 which specify the code page, and the lower
16 which you didn't reference) into "code page 0", meaning
all upper 32 bits were 0.  Sorry if this wasn't clear.  In
practice, everyone ignores the upper 32 bits, since they
have no real technical reason for existing at this time,
only political ones.

-- Terry Lambert

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 19 Nov 1999 17:36:44 -0500

>standard; I think you could argue for a loose interpretation

SRV record defines the server field to be a domain name. 
Currently defined label type for textual domain names mandates 
case folding. 

A new label type on the other hand might dictate case sensitivity. 

DO NOT bother proposing a new label type at this point!

Once we know how to solve the Internationalization and Localization 
issues, a new type or types will be defined that will support that. 

>make the (ugly, IMO) rule "receiver folds before decoding".

I know some people that will yell quite loudly at you,
if you propose something like this. 

>exclusion of normal ASCII data.

I feel almost like telling them to create their own mapping for names
that expresses case sensitivity. One simple one is to have the 
upper case characters followed by a special character. For example "#". 
	Kerberos	DNS
	naicom ===> naicom
	Naicom ===> n#aicom
	MITEDU ===> m#i#t#e#d#u#

As these names are not for human consumption something like this 
SHOULD work ,-)

	Olafur

--------
Olafur Gudmundsson - NAI Labs 			(443)-259-2389 
The Security Research Division of Network Associates, Inc.
[email-masked]  [email-masked]  Private: [email-masked]

---

From: Terry Lambert <[email-masked]>
Date: Fri, 19 Nov 1999 16:13:09 -0800

Olafur Gudmundsson wrote:
> Once we know how to solve the Internationalization and
> Localization issues, a new type or types will be defined
> that will support that.

I guess that transitive closure on this would ask the
question:

	"Should SRV wait until after that because of
	 Kerberos and other potential users requiring
	 effectively "binary" data?"

which is sort of what I was getting at, if case folding has
to be maintained for purely historical reasons.

[ ... UTF-5 and other data munging for non-folded case
      round tripping in the restricted DNS alphabet ... ]

> if you propose something like this.

8-).  You'll recognize me; I'll be up front, throwing the
tomatos at the proposer...

[ ... "Kerberos, fix thyself" ... ]

> As these names are not for human consumption something like this

Heh.  This is as gross as UTF-5 for the job...

-- Terry Lambert

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sun, 21 Nov 1999 03:46:07 +0100

This is not terribly relevant to DNS itself, but I like information to be
as correct as I can make it.....

>ignored this because of Intel-centrism, so we must deal

I believe it is more correct to say that the Unicode consortium
never got enough agreement within itself to be draconian about it.
More discussion in draft-hoffman-utf16-05.txt.
I prefer UTF-8 as a wire encoding; it does not have the byteorder
problem, and allows for direct encoding of all Unicode characters
(all planes).

>have no real technical reason for existing at this time,

ISO 10646 is 31 bits :-)
16 bits are not enough - John McCarthy proposed 17 bits in RFC 373,
back in 1972......

The following scripts have been provisionally approved for Plane 1:

·       ·       Shavian
·       ·       Etruscan
·       ·       Gothic
·       ·       Linear B (·     see also the overview for Aegean scripts)
·       ·       Cypriot syllabary (·    see also the overview for Aegean 
scripts)

The following scripts have been proposed for Plane 1:

·       Basic Egyptian Hieroglyphics
·       Meroitic
·       Old Persian Cuneiform
·       Ugaritic Cuneiform
·       Tengwar
·       Cirth
·       tlhIngan Hol
·       Brahmi
·       Old Permic
·       Sinaitic
·       South Arabian
·       Pollard
·       Blissymbolics
·       Soyombo

Info from http://www.unicode.org/pending/pending.html

Plane 2 is also set aside for "additional ideographic characters", 
according to http://anubis.dkuug.dk/JTC1/SC2/WG2/docs/projects#10646-1

In addition, there are the language tags in Plane 14, which nobody likes, 
not even the proposers, but
they've been approved :-)

                Harald

--
Harald Tveit Alvestrand, EDB Maxware, Norway
[email-masked]

---

From: Terry Lambert <[email-masked]>
Date: Mon, 22 Nov 1999 12:49:49 -0800

Harald Tveit Alvestrand wrote:
> 
> This is not terribly relevant to DNS itself, but I like
> information to be as correct as I can make it.....

[ ... Unicode byte order ... ]

> I believe it is more correct to say that the Unicode
> consortium never got enough agreement within itself
> to be draconian about it. More discussion in
> draft-hoffman-utf16-05.txt.

My copy of the 1.0 specification states that it is 16
bits in Motorolla byte order, and the selection of the
byte order identifier supports this for a state-based
data recognizer, which was discussed in detail on
comp.std.internat, back when usenet was marginally
useful.  They may not be draconian about it, but the
precedent has been set (not to mention that the IBM
and Apple folks at Taligent were using Motorolla byte
order machines).

I guess it's correct to say that the IETF wasn't
really consulted on this, ay more than DCE RPC.

> I prefer UTF-8 as a wire encoding; it does not have
> the byteorder problem, and allows for direct encoding
> of all Unicode characters (all planes).

I think you are mistaken.  Multibyte sequences are not
byte order specified.  One would logically assume that
it was a stream encoding of some kind, but that's not
the only possible interpretation.  In any interpretation,
there is a scanner restart problem.

This is way off topic, but I dislike UTF-8 because of
legacy 8 bit NFS systems exposing ISO_8859-X based name
spaces, and because of the inability to use fixe size
records, or predict space utilization.  In particular,
a 256 character directory entry could use 512 octets
in UTF-16, but will use up to 1280 octets if it happens
to be "unlucky".  UTF-8 is ASCII bigotry, and it is
worse than that, in that a hell of a lot of code and
algortihms depend on fixed-field for storage, buffers,
etc. (and rightly so).  There are similar issues with
record counting, where what used to be simple division
by record size is now an iterative process.

> ISO 10646 is 31 bits :-)
> 16 bits are not enough - John McCarthy proposed 17 bits
> in RFC 373, back in 1972......

[ ... ]

> The following scripts have been provisionally approved for Plane 1:

[ ... dead languages ... ]

> The following scripts have been proposed for Plane 1:

[ ... more linguistic scholarship ... ]

> according to http://anubis.dkuug.dk/JTC1/SC2/WG2/docs/projects#10646-1

Are they ever going to address the inherent rendering
technology bias in favor of Adobe and in opposition to
fixed cell rendering technologies, like X11, that comes
from not interleaving sufficient private use space in
fonts for languages like Tamil and Devengari, preventing
me from providing a pre-rendered ligatured font for Tamil,
for example?

> In addition, there are the language tags in Plane 14, which
> nobody likes, not even the proposers, but they've been
> approved :-)

Ugh.
"grep -v <clense document all heathen text without this tag>".
Brilliant.  8-(.

-- Terry Lambert

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 22 Nov 1999 22:47:41 +0100

>there is a scanner restart problem.

I'm reading UTF-8 as a byte stream encoding, yes. The Arpanet people blew 
bit order encoding back in the early 60s, but I think we've all agreed that 
it's too late to fix that.

The somewhat bizarre encoding of UTF-8 makes finding character boundaries 
relatively easy.

>This is way off topic,

yes :-)

>  but I dislike UTF-8 because of
>spaces,

which is IMHO a non-fixable problem unless we assume X=1 anyway

>  and because of the inability to use fixe size
>to be "unlucky".

>   UTF-8 is ASCII bigotry, and it is
>etc. (and rightly so).

Depends on your particular religion with the term "character" as applied to 
combining characters. The number of UTF-8 bytes you can need to fill up a 
single character cell position is quite horrendous; as soon as you have 
combining characters, you're already victim to the "half-truncated 
character" problem, and have to be complex about these things, I think.
(Greek, Thai, Latin-based Vietnamese and Arabic are particularly prone to 
combining character overload, I think. <NOTE: Uninformed opinion!>).

>me from providing a pre-rendered ligatured font for Tamil,

My guess is that they are not, and that if confronted, the relevant 
comittees will claim that the question belongs on the other side of the 
character/glyph delimiter they've erected around their standards effort.

But that's my 10.000 foot view.....

                               Harald

---

From: "Martin J. Duerst" <[email-masked]>
Date: Tue, 23 Nov 1999 18:19:27 +0900

>> draft-hoffman-utf16-05.txt.

Unicode people knew about the endianness problem early on,
and tried to do their best. But not all people read the
standard, and not to all of them was the boundary between
internal use (where you can use your machine byte sequence)
and data interchange clear (and it's indeed not fully clear,
what about memory-mapped files?).

> My copy of the 1.0 specification

A bit outdated. But now that 3.0 will be out soon,
maybe better wait for that than buy 2.0.

> the only possible interpretation.

The fact that nobody has seen any UTF-8 with the
bytes of a character reversed seems to show that
this is only a theoretical argument. The fact that
in UTF-8, it's clear which byte you need first to
decode helps a lot. 

> legacy 8 bit NFS systems exposing ISO_8859-X based name

This is a problem not only in NFS. But because of the
regularity of UTF-8, it turns out that it's not that
serious in practice.

> records, or predict space utilization.

There are a lot of ways to count characters. Counting
UTF-16 code units is one way, but that counts two
units for everything beyond plane 0. And not everything
in plane 0 should be counted as 1.

> me from providing a pre-rendered ligatured font for Tamil,

Sorry, but there is a very inherent cultural bias in
fixed cell rendering technologies (just for the record,
X11 is NOT fixed-cell). Technology should be upgraded
where necessary, not culture downgraded. Non-proportional
fonts are a legacy of typewriters.

Regards,   Martin.

---

From: Terry Lambert <[email-masked]>
Date: Tue, 23 Nov 1999 16:31:46 -0800

Harald Tveit Alvestrand wrote:
>> In any interpretation, there is a scanner restart
>> problem.
>  
> I'm reading UTF-8 as a byte stream encoding, yes.
[ ... ]
> The somewhat bizarre encoding of UTF-8 makes finding
> character boundaries relatively easy.

Granted, if you assume transmission order on the octets
making up a multibyte encoding.

> > I dislike UTF-8 because of legacy 8 bit NFS systems
> > exposing ISO_8859-X based name spaces,
> 

You fix it by attributing the FS in the kernel on the
client, and round-tripping in and out of the native
character set.  This works for ISO-2022-JP and any
other multibyte or NRCS encoding on the NFS server.

-- Terry Lambert

---

From: "Martin J. Duerst" <[email-masked]>
Date: Wed, 24 Nov 1999 11:28:42 +0900

> making up a multibyte encoding.

Which is what everybody is doing. If you think this needs
further specification, why don't you write an informational
RFC entitled something like "Details of the transmission
byte order of UTF-8".

> other multibyte or NRCS encoding on the NFS server.

Does it? How do you know, at the client, which encoding
is used on the server/on the wire? And in case you do,
somehow, it's easy to use that information to indicate
that it's now UTF-8.

Regards,  Martin.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 24 Nov 99 22:42:08 JST

Harald;

> The somewhat bizarre encoding of UTF-8 makes finding character boundaries 

If "character boudary" of UTF-16 were defined properly, yes.

However, 16bit fixed "character" of UTF-16 does not make any sense.

Even unicode consortium is trying (in vain) to define normalization
of representations of characters in various different single or
multiple byte encodings that the "16bits are the character" fallacy
is now non existent.

> combining character overload, I think. <NOTE: Uninformed opinion!>).

With about 20 bits of encoding space, there is no need to use things
like "combining characters" to encode Thai, Hangul, Arabic, Devanagali
or any other characters.

Anyway, Unicode/ISO10646 is so silly that, in the real world, people
continue to use ISO 2022 based encoding without bothering to convert
to the useless.

So, why do we have to waste ML bandwidth on it?

							Masataka Ohta

---

From: Terry Lambert <[email-masked]>
Date: Wed, 24 Nov 1999 09:02:51 -0800

> RFC entitled something like "Details of the transmission

I know that you're chiding me, but there are plenty of
companies that love to take advantage of ambiguities in
order to intentionally create non-interoperable code.

I dislike fuzzy definitions that allow them to do this;
UTF-8 is not the only fuzzy RFC.

If we wanted fuzzy standards, we'd go to POSIX, which
likes to standardize by fiat by documenting existing
implementations favored by committee members.  Then
you get strictly conforming implementations that don't
do the right thing, like locks that go away when one
descriptor is closed, or FreeBSD's tty revocation and
process group signal handling non-propagation of SIGHUP.

[ ... legacy NFS systems alreadyusing the 8th bit ... ]

> somehow, it's easy to use that information to indicate

You know at the client because you are the human that
specifies the mount parameters, and it is your job to
know that when attempting to mount legacy NFS systems
from non-legacy clients.

Just saying "it's now UTF-8" is not going to modify the
contents of the directory entry blocks on the legacy
system exporting its FS to the client via NFS; they
will still contain data in the legacy encoding.  The
only way to deal with this is to either disallow legacy
data, or to do client attribution of the namespace on
the supposedly more-intelligent-because-they-are-UTF-aware
clients.

-- Terry Lambert

---

From: Terry Lambert <[email-masked]>
Date: Wed, 24 Nov 1999 09:14:51 -0800

> So, why do we have to waste ML bandwidth on it?

To obtain a universal encoding that not only has the
ability to specify upper and lower case realm names
with Kerberos using SRV RR's, but that we also will
not be required to change in the forseeable future
in order to support non ASCII, non ISO_8859-1 data
when someone complains that they can't have a Tamil
realm name or other resource in an SRV RR.

-- Terry Lambert

---

From: William King <[email-masked]>
Date: Wed, 24 Nov 1999 15:49:58 -0600

Terry Lambert wrote:

> implementations favored by committee members.

I am curious. What are your qualifications for making
such a sweeping generalization ? Which POSIX committees
did you work on and for how long ?

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 28 Nov 99 2:14:12 JST

Terry;

> realm name or other resource in an SRV RR.

That's a localizaiton issue and trying to be "universal" is wrong.

DNS has the global scope and people using DNS has local scopes.

Some people are living with case insensitive Latin, some with
case sensitive Latin, some with Tamil.

It does not make sense to blindly "universally" present Tamil realm
name to everybody.

Tamil should be presented only when the locale is Tamil and applications
know how to process Tamil locale.

The encoding format of Tamil characters is a local issue local to
Tamil locale and applications which support Tamil locale.

For case sensitive Latin locale of Kerberos, UNIX traditonally has
been using '\a' for 'A'. Copy it.

							Masataka Ohta

---

From: Randy Bush <[email-masked]>
Date: Sat, 27 Nov 1999 13:11:04 -0800

> know how to process Tamil locale.

when my tamil friend sends email, what should i see in the fqdn of the from:
line of the header?

personally, i don't think i care, except that i want to be able to put it in
my .mailrc so i can send mail to them later.

randy

---

From: Randy Bush <[email-masked]>
Date: Sat, 27 Nov 1999 22:28:03 -0800

> If you can recognize Tamil characters

let's presume i can't.  but in this case i don't think i need to be able to
read it as anything sensible.

>> personally, i don't think i care, except that i want to be able to put it
>> in my .mailrc so i can send mail to them later.
> As OSes are not compatible with 8 bit characters, your .mailrc MUST
> be limited 7bit ASCII graphic characters.

i don't think that i care.  and my .mailrc takes 8-bit anyway.  though i
think i correspond with friends who might like to use glyphs that take more
than 8 bits.

i suspect what i want is to be able to cut/copy and paste the email address,
local part plus fqdn.  i.e. what matters is that it survive being taken out
of a from: header, saved in an address book, put in some future to: header,
and then looked up in the dns to get an A RR, possibly via an MX.

and through all this, it is acceptable if i can not 'read' it visually.
this is what may be meant by 'localization'.

randy

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 28 Nov 99 9:38:23 JST

Randy;

> when my tamil friend sends email, what should i see in the fqdn of the from:

If you can recognize Tamil characters, set your locale properly
and if your Tamil friend can understand Tamil characters and use
case-insensitive-ASCII-encoded Tamil characters in fqdn, your local
application may present the fqdn in Tamil characters.

> my .mailrc so i can send mail to them later.

Very important point.

For example, Windows in Japan, China, Taiwan, Korea all use different
Shift-JIS like encoding.

UNIX OSes mostly prefer EUC based encoding.

						Masataka Ohta

---

From: Robert Elz <[email-masked]>
Date: Mon, 29 Nov 1999 00:55:44 +1100

Date:        Sun, 28 Nov 99 9:38:23 JST
    From:        Masataka Ohta <[email-masked]>
    Message-ID:  <[email-masked]>

  | If you can recognize Tamil characters, set your locale properly

That's not a solution, as to use that I'd have to know in advance where
mail was going to be coming from, so I could set the locale to the correct
value - and then go change it whenever mail might be arriving from somewhere
else.

It isn't important that the labels be displayed using the same glyphs as would
be displayed to someone more knowledgeable, it is important that the strings
I receive be looked up, and transmitted back again as they arrived, so those
to whom they do make sense see what they're expecting to see.   As Randy
suggested, it doesn't matter much what the address looks like when my mailer
(or whatever) displays it to me - if I get enough such mail, and it would be
meaingful, I can arrange for better display, if it is rare, I will suffer
ugly looking addresses.   They just need to be functional.

  | and if your Tamil friend can understand Tamil characters and use
  | case-insensitive-ASCII-encoded Tamil characters in fqdn,

If - but another reasonble method is to simply put some fairly universal
encoding of the characters in the various headers (then encoded in whatever
method the various standarsd require - mail headers will have =?... noise)

  | As OSes are not compatible with 8 bit characters, your .mailrc MUST
  | be limited 7bit ASCII graphic characters.
  | 
  | For example, Windows in Japan, China, Taiwan, Korea all use different
  | Shift-JIS like encoding.
  | 
  | UNIX OSes mostly prefer EUC based encoding.

None of this has anything to do with anything.   As long as the characters
are correctly transferred in some universally agreed format, how I get them
to and from my local OS for storage is my problem (or my application vendor's
problem) - that's just a SMOP, and while in some environments it ends up
all being pretty ugly, this truly is a local issue.

kre

---

From: Randy Bush <[email-masked]>
Date: Sun, 28 Nov 1999 07:32:12 -0800

>> i don't think that i care.  and my .mailrc takes 8-bit anyway.
> Do you have any experience on 8-bit character codes?

some.  hacked a database product deal with euc, and have had to deal with
jis and shift-jis.  but i am FAR from expert.

> My Windows95 use Shift JIS text, which means if text editors edit
> a file containing Unicode 8 bit, the editors think the file contains
> invalid character codes and deleteor fix the invalid codes.
> 
> That is, I nor you can't edit our .mailrc.

my editor does not mind 8-bit.  but i did not mean to say that i wanted to
edit the .mailrc, only that i needed to get stuff out of a from: line into
my .mailrc (or whatever you use for an address book), save it there, move it
later into a to: email header such that my mail transfer agent can find the
target MX/A in the dns and deliver.

> You can not do so with 8-bit.

actually, i can.  though i know others can not. <g>

what i am trying to say is that i think it is important that we be able to
  o save addresses from anyone
  o send email to those addresses both as replies or later to:/cc:
  o get my browser to go to a url sent in an email

things i do not think i can expect to be able to do
  o type a 'foreign' email address when i see it in the foreign language
    on a visit card
  o type a 'foreign' url in

i.e. when the stuff is in the machine, the machine should be able to use it,
even if i can not 'see' it properly and/or i can not type it.

is this unreasonable?

randy

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 28 Nov 99 17:51:56 JST

Randy;

> and through all this, it is acceptable if i can not 'read' it visually.

That is not a problem.

							Masataka Ohta

---

From: Mats Dufberg <[email-masked]>
Date: Sun, 28 Nov 1999 22:08:33 +0100 (CET)

> even if i can not 'see' it properly and/or i can not type it.

That sounds fairly reasonable, but I think we need to add the requirement
that you can see all codes in the address, or you will have a hard time
being able to handle it. What I mean is that the array of bytes that the
address is represented with must correspond to printable characters on
your local machine. Recoding as in URL's with %XX is one way of acheiving
that.

Mats

-----------------------------------------------------------------
Mats Dufberg                                    [email-masked]
NIC-SE                                           +46-8-545 857 06
Box 5774                                    fax: +46-8-545 857 29
SE-114 87 Stockholm                         http://www.nic-se.se/

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 29 Nov 99 9:34:27 JST

Kre;

> That's not a solution,

Solution to what?

> as to use that I'd have to know in advance where

You may set your locale "Latin, Tamil and whatever characters I know".

> method the various standarsd require - mail headers will have =?... noise)

The only universal encoding is ASCII (or subset of once ISO646 IRV).

> are correctly transferred in some universally agreed format, how I get them

Please don't repeat UTF-8 fallacy.

								Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 29 Nov 99 9:22:41 JST

Randy;

> jis and shift-jis.  but i am FAR from expert.

So, why can't you simply accept the reality that Unicode is NOT used
at all, dispite all the efforts of unexperts?

Experts want to simply ignore Unicode.

> target MX/A in the dns and deliver.

Your editor can not handle 1.5 characters.

> actually, i can.  though i know others can not. <g>

Suppose you have 3 bytes of a UTF-8 character, which may be interpreted
as 1.5 characters in Shift JIS?

This is a variation of a well known UTF-8 fallacy.

> what i am trying to say is that i think it is important that we be able to

You can not.

Please do not waste the ML bandwidth further.

							Masataka Ohta

---

From: Randy Bush <[email-masked]>
Date: Sun, 28 Nov 1999 16:35:26 -0800

>>>>>> personally, i don't think i care, except that i want to be able to
>>>>>> put it in my .mailrc so i can send mail to them later.

i missed the part where i advocated unicode.  heck, i missed the part where
i even mentioned unicode.

> Your editor can not handle 1.5 characters.

true.  but, i hope not overly relevant.

>> what i am trying to say is that i think it is important that we be able
>> to local part plus fqdn.  i.e. what matters is that it survive being
>> taken out of a from: header, saved in an address book, put in some future
>> to: header, and then looked up in the dns to get an A RR, possibly via an
>> MX.
> You can not.

aside from being rude, which is pretty boring, would you care to explain
why in technical terms?

randy

---

From: Randy Bush <[email-masked]>
Date: Sun, 28 Nov 1999 16:56:38 -0800

> An example of simple technical facts recognized by experts is:
>   as 1.5 characters in Shift JIS, your OS can not handle.

you might note that i am specifically not asking that my opsys attach any
semantics to the octet string or to parse it in any way beyond knowing its
boundaries.  

all i am asking is that, if you send some octet string as domain data, that
my system be able to store it as an uninterpreted octet string and then pass
it as a dns resolution request to the global dns.

and, if a people's systems can not do that, you should not be sending the
domain data.

> IETF is not a place for boring debates between rude inexperts.

you flaunt decades of tradition!  <g>

randy

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 29 Nov 99 9:44:29 JST

Randy;

PERIOD.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 29 Nov 99 10:22:03 JST

Randy;

> semantics to the octet string or to parse it in any way beyond knowing its

Octet strings with multioctet characters do have encoding-dependent
syntax that your opsys or your editor can not detect boundaries without
knowing the syntax of the encoding.

Don't assume ISO-8859-*, EUC encoded ISO 8859 family, which use
singleoctet characters only.

> it as a dns resolution request to the global dns.

You can satisfy yourself with 7bit case-insensitive DNS.

However, you, in addition, said "8bit clean" and ".mailrc", which is
wrong.

You edit your ".mailrc". Your applications must be able to detect
line and other boudnaries in ".mailrc".

You can satisfy yourself with 7bit case-insensitive DNS.

> and, if a people's systems can not do that, you should not be sending the

People's systems are already doing that.

You should not say "8bit clean".

							Masataka Ohta

---

From: Randy Bush <[email-masked]>
Date: Sun, 28 Nov 1999 18:06:33 -0800

> knowing the syntax of the encoding.

my opsys needs know nothing.  my mail user agent needs to know where the
rhs of an email address can be found.  if your favorite encoding prevents
that, then you may not want to use it when generating email headers.

as far as editors go, i think i understand the problem.  your current
system is not able to parse 7-bit ascii, at least when it repeatedly says
that no one else here is discussing editing this stuff. :-)

> You can satisfy yourself with 7bit case-insensitive DNS.

due to an accident of history, i am quite satisfied.  unfortunately, the
majority of the world is not.  i am trying to understand what might
prudently be done to accommodate some of their needs.

> You edit your ".mailrc".

not necessarily.  those mailing list members whose systems can handle 7-bit
ascii may have noted that no where have i said that i want to use an editor
on the email addresses.  of course, i guess your system will not let you
parse this paragraph.

> Your applications must be able to detect line and other boudnaries in
> ".mailrc".

this is a good point.  address books which assume 7-bit and other simple
encodings may have to be enhanced if one wants to save addresses of folk
with more complex encodings than 8859 and its friends.

in my current .mailrc, email addresses are quote delimited.  i imagine that
an address-book which can handle more sophisticated encodings will need
something with out of band delimiting, i.e. length fields.

> You should not say "8bit clean".

accepted.

randy

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 29 Nov 99 11:40:55 JST

Randy;

> my opsys needs know nothing.

Your opsys will display characters, but not bytes, and you cut 2, but
not 1.5, characters of 4, but not 3, bytes.

The forth character may be systactically important one.

> system is not able to parse 7-bit ascii,

Thank you very much.

Window'95, of course, can not do anything properly.

> at least when it repeatedly says

No one else other than those who said "cut and paste".

							Masataka Ohta

---

From: Terry Lambert <[email-masked]>
Date: Mon, 29 Nov 1999 10:15:17 -0800

This should perhaps be in the iDNS working group, but I
see little value in a (non-i)DNS working group if there
is an iDNS working group that supercedes its charter, so
I will post this here.

> That's a localizaiton issue and trying to be "universal"

I disagree.  It is important for computer systems to
interoperate across arbitrary geopolitical boundaries.
This is true despite the opinions of geopolitical
parties who view the boundaries as being important for
local political reasons.  It is not the purpose of the
IETF, in my opinion, to recognize such boundaries, or
to ratify standards which implicitly recognize such
boundaries.

Being non-"universal" damages the ability to interoperate,
since character set encoding would need to be discovered
using some covert channel, otherwise.  Until such a channel
has been standardized, requiring it to exist is broken.

> DNS has the global scope and people using DNS has local

I agree, if these locally scoped people are on non-routed
networks not attached to the larger internet.

Let us not forget that the purpose behind DNS naming is
quickly being obsoleted by URLs/URIs in either clickable
or machine readable contexts which have nothing to do
with the naming.  For these applications, you might as
wll use numbers, or restrict yourself to the smaller DNS
alphabet, if you require a rendesvous that numbers can't
provide.

The primary utility of localized DNS names is for use on
business cards and other media advertisement which can
not support a machine facade to hide the implementation
details of changing that name into an IP address from the
intended user.

In other words, print, radio, and television advertising.

> Some people are living with case insensitive Latin,
> some with case sensitive Latin, some with Tamil.
> 
> It does not make sense to blindly "universally" present
> Tamil realm name to everybody.

Actually, it does.

What you are presenting, in all likelihood, is merely
a Schelling point to allow a machine intermediated URI/URL
to be looked up in the DNS in order to find the location
of the resource.

In this context, it makes perfect sense to externalize
the resource to non-Tamil speakers: it is the True Name
of the location of the resource, and is never visible to
the user of the resource.

> Tamil should be presented only when the locale is Tamil
> and applications know how to process Tamil locale.

One could easily expect that the English page of a company
in a Tamil using location will have been prepared by Tamil
using webmasters, and that as such, though the contents of
the page are English, the comments and markup on the page,
including the URIs/URLs, will be written in Tamil.

Likewise, consider the Japanese page of a local tourist
bureau or chamber of commerce in a Tamil using location.

In other words, we are talking about structural data, not
presentation data.

> The encoding format of Tamil characters is a local issue
> local to Tamil locale and applications which support
> Tamil locale.

This includes, I believe, all HTML browsers that expect to
be able to support access to English pages on Tamil-named
servers, prepared by Tamil-using HTML authors and system
and DNS adminstrators.

> For case sensitive Latin locale of Kerberos, UNIX
> traditonally has been using '\a' for 'A'. Copy it.

RFC it, first.

If the convention is not universal, it is not useful, as
it will be non-interoperable with those people not
following the convention because they are not restricted
by standards to doing so.

-- Terry Lambert

---

From: Terry Lambert <[email-masked]>
Date: Mon, 29 Nov 1999 10:32:42 -0800

Masataka Ohta wrote:
> Suppose you have 3 bytes of a UTF-8 character, which may
> be interpreted as 1.5 characters in Shift JIS?
> 

UTF-8 is not Unicode.  It is a poor (as you point out)
method of encoding it.

If you don't use a poor method of encoding it, your
problem with Unicode goes away (unless your problem
is the use of Chinese dictionary order, which came
about as a result of the Chinese classification scheme
being able to classify all of the characters in the
unified set).

Shift-JIS has this same problem, as does any multibyte
encoding that is not a raw bitwise encoding of the data
(i.e. fixed number of octets for every character).

-- Terry Lambert

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 30 Nov 99 8:23:30 JST

Terry;

> UTF-8 is not Unicode.

Who said UTF-8 Unicode?

> It is a poor (as you point out)
> method of encoding it.

Of course. All the encoding methods of Unicode are poor, because
Unicode is poor.

> problem with Unicode goes away

Are you talking about UTF-16 fallacy?

Suppose you have 2 bytes of a UTF-16 character, which may be interpreted
as an ASCII and 0.5 Shift JIS characters?

> (unless your problem

Red herring.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 30 Nov 99 10:34:38 JST

Terry;

>>> It is a poor (as you point out) method of encoding it.
>> 
>> Of course. All the encoding methods of Unicode are poor,
>> because Unicode is poor.
> 
> This is a rather silly statement.

Any statement on Unicode, including mine or yours, is silly ass, of course.

But, that is not my fault.

> No, I am not talking about _any_ multibyte encoding;
> as you point out, UTF-16 has the same problems as
> UTF-8, because it is a multibyte encoding.

Wrong.

The question is whether applications know character boundary or not.

Everything works fine if an application know some code use UTF-8 style
character boundary or another code use "singlebyte encoding" (that is,
"character boundary" == "byte boundary").

> Anticipating a complaint about byte order in 16 bit
> values, you can do one of the two following:

So, your point was 16bit byte fallacy. Sorry to have mistaken it
as UTF-16 fallacy.

						Masataka Ohta

---

From: Terry Lambert <[email-masked]>
Date: Mon, 29 Nov 1999 17:12:56 -0800

> Suppose you have 2 bytes of a UTF-16 character, which
> may be interpreted as an ASCII and 0.5 Shift JIS
> characters?

You neglected to quote where I addressed this in the
message to which you are responding; I will repeat it
for you:

| Shift-JIS has this same problem, as does
| any multibyte encoding that is not a raw bitwise
  ------------------------------------------------
| encoding of the data (i.e. fixed number of octets
  --------------------
| for every character).

I am talking about using a raw bitwise encoding,
not a multibyte encoding, e.g. an unsigned 16 bit
value.  There are exactly two octets for every
character, whether they be ASCII characters,
Japanese characters, or Tamil characters.

For your example of an ASCII character followed by
0.5 Shift-JIS characters, I would say:

1)	Throw out Shift-JIS; we are not encoding
	using variable length multibyte encoding.

2)	Your ASCII character uses exactly one u_int_16.

3)	Your 0.5 Shift-JIS characters example is a
	red herring.  The correct answer is another
	u_int_16 containing a single _whole_ Japanese
	character.

If you _choose_ to round trip the u_int_16 character
from #3 into Shift-JIS to accomodate your legacy
software, feel free to do so, but don't make me
wire-encode it that way.  How an application sees the
data is not relevent to how it is wire-encoded.

1)	Define it to be network byte order.

2)	Prefix the data with the byte order
	indicator (also a u_int_16 value) to
	disambiguate it.

Encoding based arguments are red herrings; we are
discussing a less restricted than the current DNS
alphabet, not how we should throw something out
because it can be encoded badly.

Note that I have _always_ advocated a fixed number
of bits for encoding Unicode data.  While it may
not be important in places already suffering under
variable length multibyte encoding, there are very
many computer science problems that are much more
easily tractable given fixed length fields in
records, fixed length input buffers, etc..  All
of these things have to be thrown out with the
bathwater when you choose to use a variable length
multibyte encoding.

It seems to me that the argument you are putting
forth naturally reduces to the idea that, unless
I set my locale to the right magic setting, I
should not be permitted to access content requiring
a DNS lookup, if it is being hosted on Tamil servers,
even if it is in English, if I can't also understand
Tamil.

-- Terry Lambert

---

From: Terry Lambert <[email-masked]>
Date: Wed, 24 Nov 1999 16:19:46 -0800

This is totally off topic now.  I have set the Reply-To to
point back to myself.

> did you work on and for how long ?

I wrote the 386BSD patchkit, the outgrowth of which were
the NetBSD and FreeBSD projects (and later, OpenBSD from
a split from NetBSD).

I worked at Novell USG (the former USL) for four years,
doing process architecture for the NetWare for UNIX
product, and kernel and file system work on UnixWare,
Solaris, and AIX.  The resulting server beat unhosted
Native Netware on the exact same hardware by 12%, while
running all UnixWare at the same time.

My first UNIX kernel experience was in 1983, over 16
years ago (that's a full licensed driver in the U.S.).

Not that this a complete C.V., but it's not relevant
for the question you are asking, anyway.  Here is the
relevant answer:

POSIX standardized existing System V practice.

One does not need to be on a POSIX committee to
recognize that releasing an fcntl() lock makes it a
bitch to implement an NFS file locking daemon that
doesn't use a descriptor per locking process per
client system.  You practly have to define a new
interface, or create an "F_NONPOSIX" fcntl() command
to turn the lock-release-on-close stupidity _off_.

One does not need to be on a POSIX committee to
recognize that the ability to release blocks in a
file should be specified, not left up to vendor
whims, so that few "POSIX compliant" systems implement
it the same way, rendering compliance meaningless.

One does not need to be on a POSIX committee to
recognize that the former BSD post-signal system
call restart behaviour saves a huge amount of work
when implementing a user space call conversion
scheduler for implementing threads, and avoids
much of the mess that is generated wrapping all
of the system calls and making extra system calls
to mask signals.

Speaking of signals and threads, why wasn't their
interaction specified?

What the heck is the value in requiring atime to be
updated for an FS to be POSIX compliant?  Was that
just so that the only way a DOS FS could be compliant
if it were mounted read-only, or was it just to make
benchmarks slow?

While we're near the topic, where the heck are mandatory
range locks?  Where are opportunity locks, so that a
hosted server and a UNIX process can interoperate
safely?

Don't get me started on caching of state; binding
sockets to IP addresses instead of interfaces, so
that you have to restart all your daemons when you
change the IP address of a interface, has got to
rank right up there with FIN-WAIT-2, waiting for two
responses to one request, with no way to recover
should the client die or not do resource tracking.

And PTHREAD_SCOPE_SYSTEM: whose stupid idea was it to
tie the pthreads implementation so directly to kernel
scheduler policy that nearly the only way to satisfy
the interface requirements is to implement kernel
threads?  Someone who only had a hammer (kernel threads),
so that SMP scalability looked like a nail?

Oh yeah, one of my favorites: didn't it ever occur to
anyone that async I/O calls for read and write are not
enough to implement a full pthreads?  Or that you might
want every other system call that could possibly block
to also be capable of being called async?  Or that you
might want it to work with networking, but need to know
the addresses (e.g. asyncrecfrom, asyncsendto)?

Finally, they missed the single most import point of
having a standard interface: being able to _turn off_
all vendor private interfaces, so that binaries that
are written on _one_ POSIX system will run on _all_
POSIX systems with the same CPU architecture, and the
requirement that this be possible or the system isn't
POSIX compliant.

Followups to me directly, please; no need to SPAM the
list any further.

-- Terry Lambert