Subject: Re: Where is Content-language defined these days?
From: Martin Duerst <[email-masked]>
To: Graham Klyne <[email-masked]>, [email-masked], [email-masked]
Date: Fri, 29 Jun 2001 10:59:44 +0900
List-Id: <ietf-822.imc.org>

Graham - Harald is working on that document. Draft at
http://www.ietf.org/internet-drafts/draft-alvestrand-content-language-02.txt

Regards,   Martin.

At 14:12 01/06/28 +0100, Graham Klyne wrote:
>As far as I can tell, the most recent document defining the 
>Content-language header is RFC1766.  But, according to the RFC index:
>
>1766 Tags for the Identification of Languages. H. Alvestrand. March
>      1995. (Format: TXT=16966 bytes) (Obsoleted by RFC3066) (Status:
>      PROPOSED STANDARD)
>
>But RFC3066 says nothing about Content-language, other than it being moved 
>to another document.  I have failed to discover what other document.
>
>#g
>
>
>------------
>Graham Klyne
>([email-masked])
>

To: [email-masked]
Xref: clerew local.mime:707
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: Mail addresses and extended character sets
Date: Fri, 29 Jun 2001 09:56:35 GMT
Lines: 41
Sender: [email-masked]

In <[email-masked]> [email-masked] writes:

>> 	=2340242a2324512a2451=.foo.ch
>> or	=2340242a2324512a24512e666f6f=.ch
>> or	=2340242a2324512a24512e666f6f2e6368=

>And the answer is that there will be only one way to do this. Again, if you
>intend to get into this issues you *really* need to follow and possibly
>participate in the IDN discussion.

No need. The answers given so far seem to indicate that my concerns are
mostly covered.

>> Another long-term solution to all this, of course, is to use UTF-8 in mail
>> headers, and then the whole problem goes away (so far as mail is concerned
>> - the DNS might still need to be fixed).

>On the contrary, using UTF-8 does NOT address this issue. See Keith's point
>above about combining and non-combining characters. Because of this a just send
>UTF-8 solution doesn't work. You need another mechanism -- IDN's nameprep --
>to deal with this problem.

No, I accept that the UTF-8 has to be normalized, at least according to
Unicode NFKC, but probably with additional limitations described in
nameprep. But at the end of that, what you have is restricted UTF-8. That
would be in a fit state to send as-is if there were an "8bit-headers"
extension to SMTP (with matching relaxation of RFC 2822). But there isn't,
so a further encoding is needed to squash it into current addr-spec
syntax. But one hopes that "8bit-headers" will remain the long-term goal.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

Date: Thu, 28 Jun 2001 09:22:00 -0700 (PDT)
From: [email-masked]
Subject: Re: Where is Content-language defined these days?
To: Graham Klyne <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

> As far as I can tell, the most recent document defining the
> Content-language header is RFC1766.  But, according to the RFC index:

> 1766 Tags for the Identification of Languages. H. Alvestrand. March
>       1995. (Format: TXT=16966 bytes) (Obsoleted by RFC3066) (Status:
>       PROPOSED STANDARD)

> But RFC3066 says nothing about Content-language, other than it being moved
> to another document.  I have failed to discover what other document.

draft-alvestrand-content-language-02.txt.

				Ned

To: [email-masked]
Xref: clerew local.mime:702
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: Mail addresses and extended character sets
Date: Thu, 28 Jun 2001 11:16:54 GMT
Lines: 31
Sender: [email-masked]

In <[email-masked]> [email-masked] writes:

>However, a single encoding is not sufficient. Regardless of the encoding
>chosen, people will send stuff that's incorrectly encoded and people will want
>to fix it up. And forbidding canonicalization midstream has been tried in the
>past, and in practice has proven to be a complete waste of time. You can write
>as many standards as you like and bellow about this all you want, but when a
>vendor is faced with the alternative of propogating something that's broken and
>which results in a downstream failure and fixing that something so it works,
>the choice the vendor will make is the latter. Customers demand solutions and
>don't care about standards violations, and if they cannot get satisfaction from
>one vendor who behaves in a purist way they will switch to another that
>doesn't.

Yes, News had this problem, though I think writers of news transports are
getting the message at last. Certainly, according to the USEFOR draft, any
morphing en route is a very severe MUST NOT. But the News situation is
simpler in that, if some site is broken abd other sites ostracise it, the
news still floods around the offending site.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

Date: Thu, 28 Jun 2001 06:16:24 -0700 (PDT)
From: [email-masked]
Subject: Re: Mail addresses and extended character sets
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

> > > 2. That there should only be ONE way to encode a given domain name (or
> > > local-part, for that matter).

> > it's very likely that things will end up this way, for the simple reason
> > that folks don't want to break existing DNS servers and caches.   so
> > even though there might be multiple ways to encode a non-ascii domain name
> > in Unicode (say, using combining and non-combining characters), after
> > canonicalization and ascii-encoding these should all fold to the same
> > representation.

Let's please not repeat the whole IDN requirements discussion here, OK?

> Yes, but what I had in mind was that, even after you had normalized the
> domain name according to the Unicode rules plus the IDN rules, you could
> still land up with a domain name like

> 	#@$*#$Q*$Q.foo.ch

> (where #@$*#$Q*$Q is some chinese characters, but the rest in in ASCII,
> and my apologies if 'ch' is not china).

China is .cn. and .ch is Switzerland.

> Now that has to be encoded to fit
> within an RFC 2822 addr-spec. The question is: Do you encode just the
> non-ASCII bits of it, or do you encode the whole lot, of can you choose
> several ways, for example (using a fairly obvious hex encoding just to
> illustrate the point):

> 	=2340242a2324512a2451=.foo.ch
> or	=2340242a2324512a24512e666f6f=.ch
> or	=2340242a2324512a24512e666f6f2e6368=

And the answer is that there will be only one way to do this. Again, if you
intend to get into this issues you *really* need to follow and possibly
participate in the IDN discussion.

> Those might all pass through mailing systems (possibly morphing along the
> way) and arrive at the correct destination, but any digital signature
> which included them would break, unless one of them is declared to be the
> canonical form.

This won't happen, but not because of any need to preserve digital signatures.

> Another long-term solution to all this, of course, is to use UTF-8 in mail
> headers, and then the whole problem goes away (so far as mail is concerned
> - the DNS might still need to be fixed).

On the contrary, using UTF-8 does NOT address this issue. See Keith's point
above about combining and non-combining characters. Because of this a just send
UTF-8 solution doesn't work. You need another mechanism -- IDN's nameprep --
to deal with this problem.

> But that solution is not
> immediately available (sendmail would break, for a start). However, Ned
> did say some while back that he would work on UTF-8 in mail headers,
> presumably as an extension to RFC 2821. Is that still his intention?

I said that before the IDN work started. Now that IDN is well underway and it
has become quite clear that any work before IDN settles on a solution is a
total waste of time, it is my intention to wait for IDN to figure out what they
are doing with domain names. That choice will then drive all sorts of other
choices, including how (and whether or not) we enhance message headers.

Look, this whole discussion is silly. You're simply repeating arguments and
that have already been made and ground that has already been covereed by IDN.
Either trust that the IDN folks know what they are doing and will address your
issues or don't trust them and get involved in the work so as to insure that
your concerns are addressed.

This will be my final mail on this topic on this list.

				Ned

Date: Thu, 28 Jun 2001 14:12:42 +0100
To: [email-masked], [email-masked]
From: Graham Klyne <[email-masked]>
Subject: Where is Content-language defined these days?
Sender: [email-masked]

As far as I can tell, the most recent document defining the 
Content-language header is RFC1766.  But, according to the RFC index:

1766 Tags for the Identification of Languages. H. Alvestrand. March
      1995. (Format: TXT=16966 bytes) (Obsoleted by RFC3066) (Status:
      PROPOSED STANDARD)

But RFC3066 says nothing about Content-language, other than it being moved 
to another document.  I have failed to discover what other document.

#g

------------
Graham Klyne
([email-masked])

From: Keith Moore <[email-masked]>
To: [email-masked] (Charles Lindsey)
cc: [email-masked]
Subject: Re: Mail addresses and extended character sets 
Date: Thu, 28 Jun 2001 09:22:48 -0400
Sender: [email-masked]

> The question is: Do you encode just the
> non-ASCII bits of it, or do you encode the whole lot

in a nutshell,

- encoding is done on a per-label basis.
- pure ASCII labels are not encoded.

so that naive comparisons of the encoded form work fine.

Keith

To: [email-masked]
Xref: clerew local.mime:701
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: Mail addresses and extended character sets
Date: Thu, 28 Jun 2001 11:11:17 GMT
Lines: 48
Sender: [email-masked]

In <[email-masked]> Keith Moore <[email-masked]> writes:

>> 2. That there should only be ONE way to encode a given domain name (or
>> local-part, for that matter). 

>it's very likely that things will end up this way, for the simple reason 
>that folks don't want to break existing DNS servers and caches.   so 
>even though there might be multiple ways to encode a non-ascii domain name
>in Unicode (say, using combining and non-combining characters), after 
>canonicalization and ascii-encoding these should all fold to the same 
>representation.

Yes, but what I had in mind was that, even after you had normalized the
domain name according to the Unicode rules plus the IDN rules, you could
still land up with a domain name like
	#@$*#$Q*$Q.foo.ch
(where #@$*#$Q*$Q is some chinese characters, but the rest in in ASCII,
and my apologies if 'ch' is not china).  Now that has to be encoded to fit
within an RFC 2822 addr-spec. The question is: Do you encode just the
non-ASCII bits of it, or do you encode the whole lot, of can you choose
several ways, for example (using a fairly obvious hex encoding just to
illustrate the point):
	=2340242a2324512a2451=.foo.ch
or	=2340242a2324512a24512e666f6f=.ch
or	=2340242a2324512a24512e666f6f2e6368=

Those might all pass through mailing systems (possibly morphing along the
way) and arrive at the correct destination, but any digital signature
which included them would break, unless one of them is declared to be the
canonical form.

Another long-term solution to all this, of course, is to use UTF-8 in mail
headers, and then the whole problem goes away (so far as mail is concerned
- the DNS might still need to be fixed). But that solution is not
immediately available (sendmail would break, for a start). However, Ned
did say some while back that he would work on UTF-8 in mail headers,
presumably as an extension to RFC 2821. Is that still his intention?

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

Date: Wed, 27 Jun 2001 09:27:37 -0700 (PDT)
From: [email-masked]
Subject: Re: Mail addresses and extended character sets
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

> > Of course. But you do that by joining the IDN list and participating in the
> > discussion there, not by holding a separate discussion elsewhere. I hope most
> > of the people interested in this topic have already done this; I certainly
> > have.

> Indeed, but I am already on as many of these lists as I can handle :-( .

Then I suggest you consider your priorities.

> > This would be reasonable if there was consensus on the basic approach to the
> > problem and all that was being argued were the details. But there isn't (quite)
> > a consensus yet, so it is impossible to be sure what the eventual solution is
> > going to look like. And while I think it highly unlikely, it is possible that
> > the eventual solution will be done as another layer and email addresses at the
> > RFC2821/RFC2822 level won't change at all. There certainly is a proposal on the
> > table with this characteristic.

> Hmmm! It looks as though I will have to wait until the dust settles a
> little. I am assuming that it will finally take the form of some encoding
> into ASCII that will satisfy the present addr-spec syntax. But my concerns
> are:

I suspect you're right, but it is nevertheless premature to move any
distance down this path.

> 1. There are too many encoding schemes around already; one hopes that
> they will come up with something identical to, or readily adaptable from,
> one of the existing ones.

Very unlikely, since the constraints on this particular encoding problem
are quite different from the constraints that have produced other
encodings.

> 2. That there should only be ONE way to encode a given domain name (or
> local-part, for that matter). Or, if there is more than one, that
> transports should be forbidden to reencode them en route. My concern here
> is that an address may have been included within something that has been
> digitally signed, and the signature may get broken. This is likely to be a
> serious issue in the case of News.

It is safe to assume that there will be a single canonical form and you
certainly will be required to use it. The DNS isn't going to do
canonicalization for you. So this is not a concern in regards to IDN.

However, a single encoding is not sufficient. Regardless of the encoding
chosen, people will send stuff that's incorrectly encoded and people will want
to fix it up. And forbidding canonicalization midstream has been tried in the
past, and in practice has proven to be a complete waste of time. You can write
as many standards as you like and bellow about this all you want, but when a
vendor is faced with the alternative of propogating something that's broken and
which results in a downstream failure and fixing that something so it works,
the choice the vendor will make is the latter. Customers demand solutions and
don't care about standards violations, and if they cannot get satisfaction from
one vendor who behaves in a purist way they will switch to another that
doesn't.

This is why RFC2822 took the approach it does. Don't expect anything different
to arise as a result of the IDN work.

> 3. That they are also concerned about these same things.

They are.

> See my concern #1. They should produce something that covers BOTH sides at
> the same time.

Given that the constraints on the RHS are far more stringent, this is already
covered. And again, there are plenty of people involved in the iDN effort who
are well aware of the need to extend their result to email addresses, so any
issue that does arise should be dealt with.

				Ned

From: Keith Moore <[email-masked]>
To: [email-masked] (Charles Lindsey)
cc: [email-masked]
Subject: Re: Mail addresses and extended character sets 
Date: Wed, 27 Jun 2001 10:29:44 -0400
Sender: [email-masked]

> Hmmm! It looks as though I will have to wait until the dust settles a
> little. I am assuming that it will finally take the form of some encoding
> into ASCII that will satisfy the present addr-spec syntax. But my concerns
> are:
> 
> 1. There are too many encoding schemes around already; one hopes that
> they will come up with something identical to, or readily adaptable from,
> one of the existing ones.

there are too many other constraints that have to be satisfied, including
concerns from users of various ideographic languages that the 63-character
per-label limit in DNS prevents them from encoding names of reasonable length
in their languages.  so you end up needing some kind of special-purpose
compression.

> 2. That there should only be ONE way to encode a given domain name (or
> local-part, for that matter). 

it's very likely that things will end up this way, for the simple reason 
that folks don't want to break existing DNS servers and caches.   so 
even though there might be multiple ways to encode a non-ascii domain name
in Unicode (say, using combining and non-combining characters), after 
canonicalization and ascii-encoding these should all fold to the same 
representation.

Keith

To: [email-masked]
Xref: clerew local.mime:698
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: Mail addresses and extended character sets
Date: Wed, 27 Jun 2001 10:05:09 GMT
Lines: 57
Sender: [email-masked]

In <[email-masked]> [email-masked] writes:

>Of course. But you do that by joining the IDN list and participating in the
>discussion there, not by holding a separate discussion elsewhere. I hope most
>of the people interested in this topic have already done this; I certainly
>have.

Indeed, but I am already on as many of these lists as I can handle :-( .

>This would be reasonable if there was consensus on the basic approach to the
>problem and all that was being argued were the details. But there isn't (quite)
>a consensus yet, so it is impossible to be sure what the eventual solution is
>going to look like. And while I think it highly unlikely, it is possible that
>the eventual solution will be done as another layer and email addresses at the
>RFC2821/RFC2822 level won't change at all. There certainly is a proposal on the
>table with this characteristic.

Hmmm! It looks as though I will have to wait until the dust settles a
little. I am assuming that it will finally take the form of some encoding
into ASCII that will satisfy the present addr-spec syntax. But my concerns
are:

1. There are too many encoding schemes around already; one hopes that
they will come up with something identical to, or readily adaptable from,
one of the existing ones.

2. That there should only be ONE way to encode a given domain name (or
local-part, for that matter). Or, if there is more than one, that
transports should be forbidden to reencode them en route. My concern here
is that an address may have been included within something that has been
digitally signed, and the signature may get broken. This is likely to be a
serious issue in the case of News.

3. That they are also concerned about these same things.

>> > Exactly. It is nothing short of sheer lunacy to worry about the LHS
>> > of email addresses when the rules for the RHS are still up the air.

>Of course. But you asked if there were "any other moves afoot" (your exact
>words) to deal with the LHS problem. And I responded that it would be
>ridiculous to consider such moves at this point. I stick by my assessment.

See my concern #1. They should produce something that covers BOTH sides at
the same time.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

Date: Tue, 26 Jun 2001 06:50:32 -0700 (PDT)
From: [email-masked]
Subject: Re: Mail addresses and extended character sets
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

> Indeed we cannot make firm proposals for email, but it would be wise to
> see what they are up to, and to stick our oar in if it looks like they are
> proposing something unsuitable.

Of course. But you do that by joining the IDN list and participating in the
discussion there, not by holding a separate discussion elsewhere. I hope most
of the people interested in this topic have already done this; I certainly
have.

> In the meantime, I can see a particular problem coming up in mailing
> moderators. Agreed it will not be settled in time for the Usefor draft,
> but it would be helpful to know in advance what the eventual solutions are
> likely to look like.

This would be reasonable if there was consensus on the basic approach to the
problem and all that was being argued were the details. But there isn't (quite)
a consensus yet, so it is impossible to be sure what the eventual solution is
going to look like. And while I think it highly unlikely, it is possible that
the eventual solution will be done as another layer and email addresses at the
RFC2821/RFC2822 level won't change at all. There certainly is a proposal on the
table with this characteristic.

> > Exactly. It is nothing short of sheer lunacy to worry about the LHS
> > of email addresses when the rules for the RHS are still up the air.

> On the contrary, if someone is inventing an encoding for use in the RHS of
> an addr-spec, then life will be much easier if they arrange things so that
> the same encoding can be used on the LHS. That is why we should be
> watching what they are up to.

Of course. But you asked if there were "any other moves afoot" (your exact
words) to deal with the LHS problem. And I responded that it would be
ridiculous to consider such moves at this point. I stick by my assessment.

				Ned

From: Keith Moore <[email-masked]>
To: [email-masked] (Charles Lindsey)
cc: [email-masked]
Subject: Re: Mail addresses and extended character sets 
Date: Tue, 26 Jun 2001 08:52:26 -0400
Sender: [email-masked]

> Indeed we cannot make firm proposals for email, but it would be wise to
> see what they are up to, and to stick our oar in if it looks like they are
> proposing something unsuitable.

Indeed.  Several of us are on the IDN list, and are watching.  It's just that
I personally find it difficult to summarize where they are, because there
are a lot of variant proposals, and there is not quite a consensus yet even
as to the basic approach (though there is a majority supporting one approach)
Perhaps someone else (Paul?) would care to summarize?

Keith

To: [email-masked]
Xref: clerew local.mime:695
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: Mail addresses and extended character sets
Date: Tue, 26 Jun 2001 09:43:50 GMT
Lines: 37
Sender: [email-masked]

In <[email-masked]> [email-masked] writes:

>> > Fine! Please can you point me to whichever of the umpteen IDN drafts
>> > addresses this particular issue?

>> even I have a difficult time keeping track.  but I don't think we should
>> even attempt to address this in email until the question of how to do it
>> in DNS is well-settled

Indeed we cannot make firm proposals for email, but it would be wise to
see what they are up to, and to stick our oar in if it looks like they are
proposing something unsuitable.

In the meantime, I can see a particular problem coming up in mailing
moderators. Agreed it will not be settled in time for the Usefor draft,
but it would be helpful to know in advance what the eventual solutions are
likely to look like.

>Exactly. It is nothing short of sheer lunacy to worry about the LHS
>of email addresses when the rules for the RHS are still up the air.

On the contrary, if someone is inventing an encoding for use in the RHS of
an addr-spec, then life will be much easier if they arrange things so that
the same encoding can be used on the LHS. That is why we should be
watching what they are up to.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

Date: Mon, 25 Jun 2001 11:33:58 -0700 (PDT)
From: [email-masked]
Subject: Re: Mail addresses and extended character sets
To: Keith Moore <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

> > Fine! Please can you point me to whichever of the umpteen IDN drafts
> > addresses this particular issue?

> even I have a difficult time keeping track.  but I don't think we should
> even attempt to address this in email until the question of how to do it
> in DNS is well-settled

Exactly. It is nothing short of sheer lunacy to worry about the LHS
of email addresses when the rules for the RHS are still up the air.

				Ned

From: Keith Moore <[email-masked]>
To: [email-masked] (Charles Lindsey)
cc: [email-masked]
Subject: Re: Mail addresses and extended character sets 
Date: Mon, 25 Jun 2001 13:28:43 -0400
Sender: [email-masked]

> Fine! Please can you point me to whichever of the umpteen IDN drafts
> addresses this particular issue?

even I have a difficult time keeping track.  but I don't think we should
even attempt to address this in email until the question of how to do it
in DNS is well-settled 

Keith

To: [email-masked]
Xref: clerew local.mime:692
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: Mail addresses and extended character sets
Date: Mon, 25 Jun 2001 08:55:32 GMT
Lines: 26
Sender: [email-masked]

In <[email-masked]> Keith Moore <[email-masked]> writes:

>> Has any thought been given to how such charsets will appear in mail
>> addresses?

>yes, folks in the IDN group have talked about it.  since there's
>already a need to encode characters that appear on the right hand
>side of an @ sign in ASCII (because there are so many applications
>that assume that domain names are ASCII), it might be that the same
>encoding convention (or a similar one) will work on the left hand 
>side of an @ signs.  

Fine! Please can you point me to whichever of the umpteen IDN drafts
addresses this particular issue?

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

From: Keith Moore <[email-masked]>
To: Keith Moore <[email-masked]>
cc: [email-masked] (Charles Lindsey), [email-masked]
Subject: Re: Mail addresses and extended character sets 
Date: Fri, 22 Jun 2001 18:52:36 -0400
Sender: [email-masked]

apologies for sending the reply to the wrong recipients.

this was a glitch - two different mh-like user agents with different
notions of the current folder.  

>         i guess that is not the point of his paper...  anyway if you want to
>         force IPv6, you can do getaddrinfo(3) with hints.ai_family = PF_INET6.
> 
> what does getaddrinfo() have to do with socket creation?

From: Keith Moore <[email-masked]>
To: Keith Moore <[email-masked]>
cc: [email-masked] (Charles Lindsey), [email-masked]
Subject: Re: Mail addresses and extended character sets 
Date: Fri, 22 Jun 2001 18:51:04 -0400
Sender: [email-masked]

        i guess that is not the point of his paper...  anyway if you want to
        force IPv6, you can do getaddrinfo(3) with hints.ai_family = PF_INET6.

what does getaddrinfo() have to do with socket creation?

From: Keith Moore <[email-masked]>
To: [email-masked] (Charles Lindsey)
cc: [email-masked]
Subject: Re: Mail addresses and extended character sets 
Date: Fri, 22 Jun 2001 17:41:43 -0400
Sender: [email-masked]

> Has any thought been given to how such charsets will appear in mail
> addresses?

yes, folks in the IDN group have talked about it.  since there's
already a need to encode characters that appear on the right hand
side of an @ sign in ASCII (because there are so many applications
that assume that domain names are ASCII), it might be that the same
encoding convention (or a similar one) will work on the left hand 
side of an @ signs.  

this would have the advantage of not breaking existing UAs and
MTAs that expect addresses to be ASCII.

Keith

Date: Fri, 22 Jun 2001 23:40:57 +0200
From: =?iso-8859-1?Q?Keld_J=F8rn_Simonsen?= <[email-masked]>
To: Charles Lindsey <[email-masked]>
Cc: [email-masked]
Subject: Re: Mail addresses and extended character sets
Sender: [email-masked]

On Fri, Jun 22, 2001 at 01:51:46PM +0000, Charles Lindsey wrote:
> 
> In the future, however, there will be newsgroup-names involving non-ASCII
> character set, such as
> 	dk.test.blåbægrød
> (That is our standard example on the USEFOR list - it means blueberry
> porridge I believe). The charset in which it will be expressed will be
> UTF-8 (it is in iso-8859-1 in this article, just so people are more
> likely to be able to read it). But emailing that to
> 	[email-masked]
> will not work because such characters are not allowed in email headers
> (and we really want an address that will pass through the present mailing
> system).

Well, please "blåbærgrød"
("bæ" actually means sh*t!, in Danish, "bær" means berry)

Kind regards
Keld

Date: Fri, 22 Jun 2001 14:32:12 -0700
To: [email-masked] (Charles Lindsey)
From: Dave Crocker <[email-masked]>
Subject: Re: Mail addresses and extended character sets
Cc: [email-masked]
Sender: [email-masked]

The current focus is on an ascii-encoding for the binary domain name 
data.  hence, it can be carried within any existing domain name processing 
software.

d/

At 06:51 AM 6/22/2001, Charles Lindsey wrote:
>Has any thought been given to how such charsets will appear in mail
>addresses? Some extension to RFC 2047, perhaps, to allow it to be used
>within addr-specs?
>
>My immediate problem is this. There is a convention that if you want to
>post a news article to comp.foo.moderated, then you email it to
>         [email-masked]
>and in due course it gets approved (or not) by the moderator, and appears
>on Usenet. Observe the convention (now built into all news systems)
>whereby each '.' in the newsgroup-name is converted to a '-'. So far, so
>good.
>
>In the future, however, there will be newsgroup-names involving non-ASCII
>character set, such as
>         dk.test.blåbægrød

----------
Dave Crocker   <mailto:[email-masked]>
Brandenburg InternetWorking   <http://www.brandenburg.com>
tel: +1.408.246.8253;   fax: +1.408.273.6464

To: [email-masked]
Xref: clerew local.mime:686
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Mail addresses and extended character sets
Date: Fri, 22 Jun 2001 13:51:46 GMT
Lines: 54
Sender: [email-masked]

There are working groups preparing revisions to the DNS to allow domain
names using all sorts of strange charsets. Effectivle, the whole of
Unicode is available, though I gather they are going to keep a pretty
tight control over what is properly allowed, with all sorts of
normalization rules, etc.

Question:

Has any thought been given to how such charsets will appear in mail
addresses? Some extension to RFC 2047, perhaps, to allow it to be used
within addr-specs?

My immediate problem is this. There is a convention that if you want to
post a news article to comp.foo.moderated, then you email it to
	[email-masked]
and in due course it gets approved (or not) by the moderator, and appears
on Usenet. Observe the convention (now built into all news systems)
whereby each '.' in the newsgroup-name is converted to a '-'. So far, so
good.

In the future, however, there will be newsgroup-names involving non-ASCII
character set, such as
	dk.test.blåbægrød
(That is our standard example on the USEFOR list - it means blueberry
porridge I believe). The charset in which it will be expressed will be
UTF-8 (it is in iso-8859-1 in this article, just so people are more
likely to be able to read it). But emailing that to
	[email-masked]
will not work because such characters are not allowed in email headers
(and we really want an address that will pass through the present mailing
system).

So we need to invent YET ANOTHER ENCODING (TM) of 8-bit into ASCII (and
this one does not have to be particularly readable, because it will be
generated automatically). So we might invent something like
	"=?utf-8?q?dk-test-bl=c3=a5b=c3=a6gr=c3=b8d?="@moderators.isc.org
which is actually perfectly legal at the moment. It is just a
quoted-string full of ASCII characters, and any resemblance to RFC 2047 is
"purely coincidental" (of course).

But my reason for bringing it up on this list is to ask whether there are
any other moves afoot to deal with problems of this nature. Because, if
there are, then I don't want to be reinventing yet more unnecessary wheels.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

From: Keith Moore <[email-masked]>
To: Jacob Palme <[email-masked]>
cc: IETF mailing list on MIME and e-mail <[email-masked]>
Subject: Re: Varying the "Display-name" 
Date: Thu, 07 Jun 2001 09:39:08 -0400
Sender: [email-masked]

> Is the following permitted/recommended?

it's certainly permitted.  nothing says that we have to use the
same name in all messages that we send, or that this name has
to correspond exactly to the sender's legal name.

> It might cause
> problems in those mailers which automatically produce address
> books based on content of incoming messages.

yes it might.   but address books that are derived in this manner
are likely to contain a fair degree of garbage for other reasons
also.

Keith

Date: Wed, 6 Jun 2001 13:13:38 +0200
To: IETF mailing list on MIME and e-mail  <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Varying the "Display-name"
Sender: [email-masked]

Is the following permitted/recommended?

One message:
      From: John Smith as chairman <[email-masked]>

Another message:
      From: John Smith as ordinary member <[email-masked]>

I cannot find anything in RFC2822 which forbids it. It might cause
problems in those mailers which automatically produce address
books based on content of incoming messages.

-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/