Subject: Re: [Sipping] I-D ACTION:draft-fujimoto-sipping-header-lang-00.txt

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 09 Oct 2002 02:46:59 -0400

Rohan Mahy wrote:
> 
>> In XML, for example, the tagging is not in-band. Its done with the  
>> xml:lang attribute:
>>
>> <subject xml:lang="de">Achtung!</subject>
>>
>> An element which doesn't understand the de tag will still properly  
>> determine that the subject is "Achtung!", and will render it in a  
>> reasonable way, without any ugly escape characters.
>>
>> We should probably do something similar in SIP. I would propose a  
>> header called Header-Lang which indicates the language of any  
>> free-form text in a header:
>>
>> Header-Lang: from;lang="de", to;lang="en"
>>
>> which says that the freeform text in the From header is in German, 
>> and  in the To field, in English. This gets a bit messy for headers 
>> like  Contact that have multiple values, each of which has freeform 
>> text  that might have a different lanugage. In that case, an index 
>> that  indicates which value can be included:
>>
>> Header-Lang: contact;index=1;lang="de",contact;index=2;lang="es"
>>
>> which says that the first contact header is in german, and the 
>> second,  in spanish.
> 
> 
> yuck!  this is hideous.  now you can't effectively perform end-to-end  
> message integrity of the complete semantic content of the from header  
> for example, because presumably, the Header-Lang header would need to  
> be modified by intermediaries in case one added an Error-Info header  
> and wanted to language tag it.

I admit this is ugly. I actually like Henning's suggestion better, to 
add a lang parameter to the From, Contact, and To headers. Subject 
header, which incidentially is the only header where there is a 
plausible argument for multiple language tags, we do something 
different. There, I also like his suggestion for a second subject header 
that supports language markup.

Anyway, from a process thing, I think, at this point, that there is 
consensus that language tagging is an interesting problem. I would 
propose that Shingo update his document, submitting just the 
requirements to sipping, and that we ask the chairs to consider taking 
this on as a new piece of work.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 9 Oct 2002 08:31:41 -0700

On Tuesday, October 8, 2002, at 11:46 PM, Jonathan Rosenberg wrote:

>>  message integrity of the complete semantic content of the from 
>> header  for example, because presumably, the Header-Lang header would 
>> need to  be modified by intermediaries in case one added an 
>> Error-Info header  and wanted to language tag it.
>
> different. There, I also like his suggestion for a second subject 
> header that supports language markup.
>
>
>

Good plan.  Lets do it.

thanks,
-rohan

---

From: Shingo Fujimoto <[email-masked]>
Date: Thu, 10 Oct 2002 10:38:27 +0900

>> this on as a new piece of work.

OK. I will do it.

First of all, I will make and post the summary of discussion later.
-- 
======================================
          SHINGO FUJIMOTO
     FUJITSU LABORATORIES LIMITED
E-mail: [email-masked]

---

From: Shingo Fujimoto <[email-masked]>
Date: Wed, 16 Oct 2002 19:59:22 +0900

Hi, there.

Here is the brief summary of header-lang discussion on SIPPING-WG ML.

Please let me know if there are any mistakes.

After I received your comments, I will start working on new I-Ds.

Thanks.

The summary of header-lang discussion

1. Why header-lang is important ?
2. Unicode 'lang-tag' vs. MIME part3 modified
3. Multiple languages in one header
4. Locale Info
5. Other solutions
6. To Do

1. Is header-lang useful ?

The text-to-speech problem is somewhat forward thinking, and it's not 
the real issue right now.

The real problem has to do with visually rendering characters in the 
CJK(Chinese Japanese Korean) range of Unicode. For example, the UA 
implementation can not choose the correct font to render CJK range UTF-8 
characters without language information.

CONCLUSION:
It is worth to solve this problem.

2. Unicode 'language-tagging' vs. MIME part3 modified

The 'language-tagging' is defined as RFC2482(Informational). That 
defined the special tag character which declare language info was 
included. However, the specification was not accepted as the part of 
Unicode standard at Unicode forum. The recommended to include those 
information as out-of-band method.
(See http://www.unicode.org/reports/tr7/ )

Shingo Fujimoto's proposal is based on MIME part3 and its extension 
(RFC2047 and RFC2231). But it is not compatible with MIME standards. 
That assume character set and encoding scheme is fixed to 'UTF-8' and 
'U-encoding'.

At this time, both of them are not standard, and non-compatible with 
currently exist UAs. As the result, they will show the tag sequence 
characters as ugly garbage.

CONCLUSION:
We need more discussion to choose the solution.

3. Multiple language in one header

Shingo Fujimoto's proposal requires it as 'MUST'. But most of other 
protocols didn't require it.

That is useful if the Subject header support it.

It is hard for users to input the mixed language text.

CONCLUSION:
The requirement should be downgraded as 'SHOULD'.

4. Locale Info.

The text in Fujimoto's I-D, "The i18n-ext MUST provide enough 
information for cultural dependent process." sounds strange.

The author thought that requires not only language but also country, and 
RFC3066 "Tags for Indication of Languages" meets this requirement.

CONCLUSION:
I-D should be rewritten to reflect comments.
# Is it OK with "The i18n-ext MUST support locale information, such as 
RFC3066 "Tags for
# Indication of Language" ?

5. Other solutions

Other possible solutions are posted:

a) language option
Specifying the language information as header option. ex. "; lang=ja"

b) Header-Language header
Define the new header to include all header language information in one 
header.
Ex. Header-Language: from=ja_JP

c) Subject-I18N header
Define the new header for Internationalized header which will support 
xml like tagging.
Ex. Subject-I18N: <lang=ja>kon ni chi wa</> <lang=en> means hello</>

CONCLUSION:
We need more discussion.

6. To DO

6.1. Split the document into two separate I-Ds (requirement and proposal)

6.2. Reflect conclusions to requirement I-D.

=END OF TEXT=

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 17 Oct 2002 01:03:52 -0400

This summary looks good. Minor comments inline.

> The requirement should be downgraded as 'SHOULD'.

I think the requirement is that it SHOULD be possible only in headers 
for which there is a real likelihood of multiple languages being input 
for that header. This is only the Subject header.

Also, we had discussed requirements for backwards compatibility. I had 
offered a requirement that said that "the language tagging mechanism 
must be such that, if receieved by a UA which doesn't support language 
tagging, the overall behavior is exactly as if the language tagging were 
not present. This implies that there should be no user interface 
artifacts, such as garbage in the headers."

-Jonathan R.

---

From: "Eric Burger" <[email-masked]>
Date: Thu, 17 Oct 2002 10:13:39 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Jonathan Rosenberg
> Sent: Thursday, October 17, 2002 1:04 AM
[snip]
> for that header. This is only the Subject header.

It would be "nice" to have it in any arbitrary header.  Who are we to say
that names (To:, From:) or other undiscovered headers will not need multiple
languages?  If we can have a uniform method of doing multiple languages,
let's do it.

Thus, I would put it differently:
The requirement MUST be possible in headers with a real likelihood of
multiple languages (Subject:).  The requirement MAY be possible in other
headers with arbitrary strings.

[snip]
> artifacts, such as garbage in the headers."

This might be too hard.  If I send you a message with multilingual headers,
my expectation is, "you speak my languages".  This is why we don't have
Subject: and Subject-Lang: in RFC 2822.  The only realistic case where that
expectation is false is spam.  Frankly, I don't care about making spam
easier to read!

---

From: "Eric Burger" <[email-masked]>
Date: Thu, 17 Oct 2002 10:13:34 -0400

I would suggest working first on the requirements document.  After another
round of discussion (in SIPPING) you will be able to work on the protocol
proposal itself (in SIP).

Given that, I would suggest that...

> Shingo Fujimoto
> Sent: Wednesday, October 16, 2002 6:59 AM
[snip]
> 2. Unicode 'language-tagging' vs. MIME part3 modified
[snip]
... is really about implementation, not requirements.  To help chose
language-tagging vs. MIME part3, you can try to get acceptance for
requirements that would result in the choice of one or the other.  For
example, you can offer that the protocol has to use Unicode; has to use
UTF-8; or has to use MIME.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 21 Oct 2002 11:59:58 -0400

> headers with arbitrary strings.

OK.

> This might be too hard. 

Not really. We have several suggestions on the table that have this 
property. A header parameter, for example.

  If I send you a message with multilingual headers,
> my expectation is, "you speak my languages". 

The issue is not whether you speak my languages. Its whether your UA 
supports the appropriate language tagging. Since exactly ZERO do at the 
moment, we have this issue.

-Jonathan R.