Subject: [Pana] Language tag review

From: Mark Townsley <[email-masked]>
Date: Mon, 06 Nov 2006 09:08:12 -0800

-------- Original Message --------
Subject: 	Re: [Fwd: Re: Looking for a Language tag expert]
Date: 	Fri, 06 Oct 2006 18:19:12 +0900
From: 	Martin Duerst <[email-masked]>
To: 	Mark Townsley <[email-masked]>, [email-masked]
CC: 	Ted Hardie <[email-masked]>
References: 	<[email-masked]>

Hello Mark,

Please see below. This review is made having no idea
what your draft is about, but I hope it helps anyway.

At 02:02 06/10/06, Mark Townsley wrote:
>
>Could one of you review this bit of text?
>
>Thank you,
>
>- Mark
>
>-------- Original Message --------
>Subject:       Re: Looking for a Language tag expert
>Date:  Thu, 5 Oct 2006 09:54:35 -0700
>From:  Ted Hardie <[email-masked]>
>To:    Mark Townsley <[email-masked]>, IESG <[email-masked]>
>References:    <[email-masked]>
>
>
>
>At 2:33 PM +0200 10/5/06, Mark Townsley wrote:
>>I would like a language tag expert to review the following text from draft-ietf-pana-pana-12.txt
>>
>>If there is someone here that can do this, great, if not, please forward on or tell me whom to forward it to.
>>
>>Thanks.
>>
>>8.11.  Notification AVP
>>
>>  The Notification AVP (AVP Code 11) is optionally used to convey a
>>  displayable message sent by either the PaC or the PAA.  It can be
>>  included in any message, whether it is a request or answer.  In case
>>  a notification needs to be sent but there is no outgoing PANA message
>>  to deliver this AVP, a PANA-Update-Request that only carries a
>>  Notification AVP SHOULD be generated.
>>
>>  The 'M' bit in the AVP header of this AVP MUST NOT be set.
>>
>>  Receipt this AVP does not change PANA state.
>>
>>  AVP data is of type OctetString and it contains the following fields
>>  in the listed order:
>>
>>  Language Tag Length
>>
>>     This field contains the length of the Language Tag in octets.  The
>>     length of this field is 2 octets.

Are these octets hex or dec? If it's hex, the length is way enough
of course. If it's dec, we still have 99 as a max, which is way
above the various limits we have in RFC 4646.

>>  Language Tag
>>
>>     This field contains the language tag defined in [I-D.ietf-ltru-
>>     registry] to indicate the language used for Displayable String.
>>     The length of this data is determined by the Language Tag Length
>>     field.

Please replace [I-D.ietf-ltru-registry] with RFC 4646, or even
better, BCP 47 (because we are already working on an update to
RFC 4646, to add much more language codes).

>>  Displayable String
>>
>>     This field contains UTF-8 encoded ISO 10646 characters [RFC2279]
>>     using the language indicated by the Language Tag. The length of
>>     this data is determined by the AVP Length field and the Language
>>     Tag Length field.  This data MUST NOT be null terminated.

Is my understanding correct that the length of this is the AVP length
minus the language tag length minus the 2 octets of the language tag
length field minus possibly some other stuff included in the AVP length?
If you are confident that the average reader of your draft will
figure this out correctly, then it's fine with me.

I assume that how the 'server' side of the protocol gets an idea
of what languages to send is also dealt with in the protocol.
Sending every language available isn't scalable, there are just
too many language. RFC 4647 (also part of BCP 47) may be relevant
for defining how the server matches language ranges in requests
or commands to the languges it returns.

Regards,    Martin.

>Martin Duerst, co-chair of ltru would be an appropriate reviewer.
>                               Ted
>

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]     

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 10 Nov 2006 02:30:30 -0500

I am concerned on the last part of review comment on matching language
range.  I strongly believe that adding matching language range
functionality is too much for a network access authentication
protocol.

I am inclined to remove Notification AVP from PANA specification.
This could be another simplification to PANA.

Yoshihiro Ohba

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 13 Nov 2006 18:59:27 +0200

I'm wondering what it takes to do range matching. Are there any examples? 

Alper

> -----Original Message-----
> From: Yoshihiro Ohba [mailto:[email-masked]]
> Sent: Friday, November 10, 2006 9:31 AM
> To: Mark Townsley
> Cc: [email-masked]
> Subject: Re: [Pana] Language tag review
> 
> > >>If there is someone here that can do this, great, if not, please
> forward
> > >>on or tell me whom to forward it to.
> > >>
> > >>Thanks.
> > >>
> > >>8.11.  Notification AVP
> > >>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 14 Nov 2006 19:52:25 -0500

OK.  Let me give several examples based on my reading of RFC 4647.
Please allow me to give very rough explanation to be concise.

Language range has a format that is very similar to language tag, but
language range is used only as input parameter for language matching.

It is assumed that matching is performed againt a pre-configured set
of language tags which are not shown in the examples.

There are two basic methods for matching, i.e., filtering and lookup.

Filtering
---------

This is used for matching language ranges to language tags 
that least matches the language ranges.

Example 1:

- Input:  en
- Output: en-US, en-UK

Example 2:

- Input:  ja, en
- Output: ja-JP, en-US, en-UK

Example 3:

- Input:  *
- Output: ja-JP, en-US, en-UK, de-DE

Example 4:

- Input:  de-*-de
- Output: de-DE, de-Latn-DE, de-Latf-DE, de-DE-x-goethe, de-Latn-DE-1996, de-Deva-DE

Lookup
------

This is used for matching language ranges to a single language tag 
that best matches with the language ranges.

Example 5:

- Input: zh-Hant-CN-x-private1-private2
- Ouput: zh-Hant-CN

Example 6:

- Input: zh-Hant-CN-x-private1-private2, zh-Hant-CN-x
- Ouput: zh-Hant-CN-x-private1

Regards,
Yoshihiro Ohba