[Pana] Language tag review

[Mark Townsley <townsley at cisco.com>]

-------- Original Message --------
Subject: 	Re: [Fwd: Re: Looking for a Language tag expert]
Date: 	Fri, 06 Oct 2006 18:19:12 +0900
From: 	Martin Duerst <duerst at it.aoyama.ac.jp>
To: 	Mark Townsley <townsley at cisco.com>, ltru-chairs at tools.ietf.org
CC: 	Ted Hardie <hardie at qualcomm.com>
References: 	<45253A9F.6050208 at cisco.com>



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 <hardie at qualcomm.com>
> To:    Mark Townsley <townsley at cisco.com>, IESG <iesg at ietf.org>
> References:    <4524FBB5.4080001 at cisco.com>
>
>
>
> 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:duerst at it.aoyama.ac.jp     


_______________________________________________
Pana mailing list
Pana at ietf.org
https://www1.ietf.org/mailman/listinfo/pana