Subject: RE: [Ltru] Access to subtag registry by matching applications

From: "McDonald, Ira" <[email-masked]>
Date: Thu, 6 Apr 2006 05:51:03 -0700

+1

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]

> -----Original Message-----
> From: Mark Davis [mailto:[email-masked]]
> Sent: Wednesday, April 05, 2006 9:40 PM
> To: Randy Presuhn
> Cc: LTRU Working Group
> Subject: Re: [Ltru] Access to subtag registry by matching applications
> 
> 
> Works for me.
> 
> Randy Presuhn wrote:
> > Hi -
> >
> > Works for me, though others, finickier than I, might complain
> > about the SHOULD.
> >
> > Randy
> >
> > ----- Original Message ----- 
> > From: "Addison Phillips" <[email-masked]>
> > To: "'Mark Davis'" <[email-masked]>
> > Cc: <[email-masked]>
> > Sent: Wednesday, April 05, 2006 5:45 PM
> > Subject: RE: [Ltru] Access to subtag registry by matching 
> applications
> >
> >
> > Alright. I did a rewrite on your suggestion, though. The 
> paragraph now reads:
> >
> > --
> > <t>Applications, protocols, or specifications, in 
> addressing their particular requirements, can offer pre-processing or
> > configuration options. For example, an implementation could 
> allow a user to associate the language subtags 'nn' (Nynorsk 
> Norwegian)
> > and 'nb' (Bokmal Norwegian) with the more general subtag 
> 'no' (Norwegian). Or perhaps the user could associate the 
> range "zh-Hans"
> > (Chinese as written in the Simplified script) with the tag 
> "zh-CN" (Chinese as used in China, where the Simplified script is
> > predominant). These options will influence the results of a 
> matching operation, so an application, protocol, or 
> specification SHOULD
> > document how ranges or tags are altered, prioritized, or 
> compared in the subsequent match so that users can modify 
> their tags or
> > language priority lists appropriately.</t>
> > --
> >
> > Addison Phillips
> > Internationalization Architect - Yahoo! Inc.
> >
> > Internationalization is an architecture.
> > It is not a feature.
> >   
> >> -----Original Message-----
> >> From: Mark Davis [mailto:[email-masked]]
> >> Sent: 2006年4月5日 16:51
> >> To: Addison Phillips
> >> Cc: 'John Cowan'; [email-masked]
> >> Subject: Re: [Ltru] Access to subtag registry by matching 
> applications
> >>
> >>  > Let's forget the MUSTard. Question is: should we even 
> mention the
> >> whole customization thing?
> >>
> >> Given that I think that any implementation that *didn't* do some
> >> customization would be unacceptable our customers, I think 
> we have to
> >> allow for it. See my previous message for suggested rephrasing.
> >>
> >> Mark
> >>
> >> Addison Phillips wrote:
> >>     
> >>> John Cowan wrote:
> >>>
> >>>
> >>>       
> >>>> (BTW, graf 2 of Section 3 still talks about information items.)
> >>>>
> >>>>         
> >>> Good catch. Changed to:
> >>>
> >>> <t>There are two types of matching scheme in this 
> document. A matching
> >>> scheme that produces zero or more matching language tags is called
> >>> "filtering". A matching scheme that produces exactly one 
> match for a
> >>>       
> >> given
> >>     
> >>> request is called "lookup".</t>
> >>>
> >>> And also:
> >>>
> >>>
> >>>       
> >>>> I don't like the last sentence.  Enabling such options 
> by default, if
> >>>>         
> >> they
> >>     
> >>>> are good ones, may be just the right thing to do: 
> conformance isn't
> >>>> anything.
> >>>>
> >>>>         
> >>> I don't like it either.
> >>>
> >>> Randy meanwhile opines:
> >>>
> >>>
> >>>       
> >>>> Not necessarily; it could also be thought of as mapping 
> a single tag
> >>>>         
> >> into
> >>     
> >>>> a set of tags or ranges before offering them to the 
> matching algorithm.
> >>>>
> >>>>         
> >>> You're correct. I said as much in my preceding paragraphs 
> too. It just
> >>>       
> >> isn't
> >>     
> >>> expressed well here. What it probably ought to say is 
> something like:
> >>>
> >>> --
> >>> Modifying the language ranges or tags can affect the 
> outcome of the
> >>>       
> >> matching
> >>     
> >>> operation.
> >>> --
> >>>
> >>>
> >>>       
> >>>> If we're clear that we're only talking about such capabilities
> >>>> being "built in" to the matching algorithm this would be ok, but
> >>>> I'm concerned that this might be misconstrued as being 
> too strong,
> >>>> e.g., forbidding an application which used a conformant matching
> >>>>         
> >> function
> >>     
> >>>> from providing these more elaborate / useful services.
> >>>>
> >>>>         
> >>> Let's forget the MUSTard. Question is: should we even 
> mention the whole
> >>> customization thing?
> >>>
> >>> Addison
> >>>
> >>> Addison Phillips
> >>> Internationalization Architect - Yahoo! Inc.
> >>>
> >>> Internationalization is an architecture.
> >>> It is not a feature.
> >>>
> >>>
> >>>       
> >>>> -----Original Message-----
> >>>> From: John Cowan [mailto:[email-masked]]
> >>>> Sent: 2006?4?5? 15:50
> >>>> To: Addison Phillips
> >>>> Cc: [email-masked]
> >>>> Subject: Re: [Ltru] Access to subtag registry by 
> matching applications
> >>>>
> >>>> Addison Phillips scripsit:
> >>>>
> >>>>
> >>>>         
> >>>>> Applications, protocols, or specifications, in addressing their
> >>>>> particular requirements, can offer pre-processing or 
> configuration
> >>>>> options. For example, an implementation could allow a user to
> >>>>> associate the language subtags 'nn' (Nynorsk Norwegian) and 'nb'
> >>>>> (Bokmal Norwegian) with the more general subtag 'no' 
> (Norwegian). Or
> >>>>> perhaps the user could associate the range "zh-Hans" (Chinese as
> >>>>>           
> >> written
> >>     
> >>>>> in the Simplified script) with the tag "zh-CN" (Chinese 
> as used in
> >>>>> China, where the Simplified script is predominant). 
> Such customization
> >>>>> affects the operation of the underlying matching 
> scheme. Conformant
> >>>>> implementations SHOULD NOT enable such options by 
> default and MUST
> >>>>> offer a configuration or mode compatible with the 
> unmodified matching
> >>>>> scheme or schemes described in this document.
> >>>>>
> >>>>>           
> >>>> I don't like the last sentence.  Enabling such options 
> by default, if
> >>>>         
> >> they
> >>     
> >>>> are good ones, may be just the right thing to do: 
> conformance isn't
> >>>> anything.
> >>>> And the second half of the sentence says that a 
> conformant application
> >>>> MUST offer a conformant mode of operation, which is to say that
> >>>> conformance
> >>>> entails conformance.
> >>>>
> >>>>
> >>>>
> >>>>         
> >>>>> --
> >>>>>
> >>>>> Thoughts?
> >>>>>
> >>>>> Addison
> >>>>>
> >>>>> Addison Phillips
> >>>>> Internationalization Architect - Yahoo! Inc.
> >>>>>
> >>>>> Internationalization is an architecture.
> >>>>> It is not a feature.
> >>>>>
> >>>>>
> >>>>>           
> >>>>>> -----Original Message-----
> >>>>>> From: Mark Davis [mailto:[email-masked]]
> >>>>>> Sent: 2006???4???5??? 11:33
> >>>>>> To: Addison Phillips
> >>>>>> Cc: 'Randy Presuhn'; 'LTRU Working Group'
> >>>>>> Subject: Re: [Ltru] Access to subtag registry by matching
> >>>>>>             
> >> applications
> >>     
> >>>>> _______________________________________________
> >>>>> Ltru mailing list
> >>>>> [email-masked]
> >>>>> https://www1.ietf.org/mailman/listinfo/ltru
> >>>>>
> >>>>>
> >>>>>
> >>>>>           
> >>>> --
> >>>> But that, he realized, was a foolish            John Cowan
> >>>> thought; as no one knew better than he          [email-masked]
> >>>> that the Wall had no other side.
> >>>>         
> >> http://www.ccil.org/~cowan
> >>     
> >>>>         --Arthur C. Clarke, "The Wall of Darkness"
> >>>>
> >>>>         
> >>>
> >>> _______________________________________________
> >>> Ltru mailing list
> >>> [email-masked]
> >>> https://www1.ietf.org/mailman/listinfo/ltru
> >>>
> >>>
> >>>
> >>>       
> >
> >
> >
> > _______________________________________________
> > Ltru mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/ltru
> >
> >
> >
> > _______________________________________________
> > Ltru mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/ltru
> >
> >
> >   
> 
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ltru
> 
> -- 
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.385 / Virus Database: 268.3.5/302 - Release 
> Date: 4/5/2006
>  
> 

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.3.5/302 - Release Date: 4/5/2006

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