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.