RE: [Pana] Language tag review
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Pana] Language tag review



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

Alper


> -----Original Message-----
> From: Yoshihiro Ohba [mailto:yohba at tari.toshiba.com]
> Sent: Friday, November 10, 2006 9:31 AM
> To: Mark Townsley
> Cc: pana at ietf.org
> Subject: Re: [Pana] Language tag review
> 
> 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
> 
> On Mon, Nov 06, 2006 at 09:08:12AM -0800, Mark Townsley wrote:
> >
> >
> > -------- 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
> >
> 
> _______________________________________________
> Pana mailing list
> Pana at ietf.org
> https://www1.ietf.org/mailman/listinfo/pana


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




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.