Re: What day is 2010-01-02

[Phillips, Addison]

(from digest)

> 
> ISO not withstanding, its still confusing if only because other
> cultures use yyddmm.  If the IETF website used something like  ISO-2010-01-02
> maybe.

Actually, for culturally-formatted date strings, cultures that prefer day-month 
order typically put the year at the trailing end. It turns out that cultures 
that put the year first in their local date format always use month-day order 
afterwards.

Unicode's Common Locale Data Repository (CLDR) project lists several hundred 
locales, which you can browse for both the sheer diversity of forms 
(separators, abbreviations, calendars, and such) within the relative 
homogeneity of overall patterns (just three: mdy, dmy, and ymd). See:

   http://www.unicode.org/cldr 

> 
> This format is less confusing:  02jan2010
> 

There are several benefits to using ISO 8601 (well, actually RFC 3339) which 
have already been reported on this thread, so I won't bludgeon the topic 
further. However, for those interested some useful links appear on here:

   http://www.w3.org/QA/Tips/iso-date
   http://www.w3.org/International/questions/qa-date-format 

Regards,

Addison

Addison Phillips
Chair -- W3C Internationalization WG

Internationalization is not a feature.
It is an architecture.



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: What day is 2010-01-02

[Phillips, Addison]

John Klensin noted:
> 
> While it doesn't change the conclusion, I've actually see many
> uses of ydm in the wild.  I haven't taken the time to try to
> find out, but I've assumed that was the reason why the current
> version of ISO 8601 moved to "one delimiter and it is hyphen"
> from the permissiveness about delimiter choices in its
> predecessors.
> 

Normally I hesitate before making sweeping statements like that :-). In this 
case, I omitted, for the sake of brevity, noting that there are many MANY 
formats in use, especially in specialized fields such as accounting, and that, 
like most anything involving culture or language, one can find nearly any 
variation, no matter how "strange" or "foreign" it seems to outsiders, that is 
actually in customary use *somewhere*. 

There is also a difference between "regularized" usage and formats derived by 
well-meaning people based on their own experience (i.e. a European might very 
well think first of ydm, being used to seeing the day preceding the month).

However, I'm unaware of any locale where 'ydm' is a *preferred* format, any 
casual or specialized usage notwithstanding. Probably someone will go find one, 
just to prove my first paragraph. In I18N, we usually say that the answer to 
any question begins with the phrase "well, it depends..."

Finally, if one is reading standards, it behooves one to understand the customs 
and language adopted there. Date formats such as this are one such example, 
just as certain English words have special meaning in a standards context. The 
use of a well-known, unambiguous format, such as ISO 8601-derived dates, is 
sensible as such a standard as it is generally inoffensive, language/culture 
neutral, and recognizable.

Addison

Addison Phillips
Chair -- W3C Internationalization WG

Internationalization is not a feature.
It is an architecture.


 

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: What day is 2010-01-02

[Phillips, Addison]

John Klensin noted:
> 
> ...  It was only the sweeping
> statement to which I was taking exception.  

Sweeping generalizations in regard to language or culture are always wrong.

~Addison

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: draft-ietf-ltru-4645bis-10.txt issue with preferred value for YU

[Phillips, Addison]

Hi Tex,

I don't think this is probably appropriate, at least for this list to consider.

1. You haven't posted to LTRU's mailing list, only ietf-languages@, yet.

2. Even if draft-4645bis is approved, the process for language tags (in either 
RFC 4646 or its proposed successor) allow you to register the information you 
want, if you think it was inappropriately omitted.

Addison

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.


> -Original Message-
> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On
> Behalf Of ietf-requ...@ietf.org
> Sent: Monday, March 02, 2009 3:43 AM
> To: ietf@ietf.org
> Subject: Ietf Digest, Vol 10, Issue 4
> 
> Send Ietf mailing list submissions to
>   ietf@ietf.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>   https://www.ietf.org/mailman/listinfo/ietf
> or, via email, send a message with subject or body 'help' to
>   ietf-requ...@ietf.org
> 
> You can reach the person managing the list at
>   ietf-ow...@ietf.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Ietf digest..."
> 
> 
> Today's Topics:
> 
>1. Re: Internet Society joins Liberty Alliance Management Board:
>   Why? (Patrik F?ltstr?m)
>2. draft-ietf-ltru-4645bis-10.txt issue with preferred value for
>   YU (Tex Texin)
>3. Terminal room at IETF74 (Dearlove, Christopher (UK))
>4. Identity Services Beyond Web SSO (was RE: [TLS] TLS WG Chair
>   Commentson draft-ietf-tls-authz-07) (Josh Howlett)
>5. New IETF Journal available now (Volume 4, Issue 3) (Mirjam
> Kuehne)
>6. Re: Internet Society joins Liberty Alliance Management Board:
>   Why? (Olaf Kolkman)
> 
> 
> ---
> ---
> 
> Message: 1
> Date: Mon, 2 Mar 2009 07:23:10 +0100
> From: Patrik F?ltstr?m 
> Subject: Re: Internet Society joins Liberty Alliance Management
> Board:
>   Why?
> To: John C Klensin 
> Cc: Hannes Tschofenig ,"Lynn St.
> Amour"
>   ,Dave CROCKER ,
>   dai...@isoc.org, ietf@ietf.org
> Message-ID: <26d2ecc5-c77f-4449-bd9f-ede6b551e...@cisco.com>
> Content-Type: text/plain; charset="us-ascii"; Format="flowed";
>   DelSp="yes"
> 
> On 2 mar 2009, at 04.12, John C Klensin wrote:
> 
> > I am not suggesting trying to undo this decision, but believe
> > that, as ISOC adds sufficient technically-qualified staff to
> > engage in activities like this on its own, we need to work,
> > collectively, on better ways to facilitate communication in a
> > timely basis in the future.  In particular, we need to work
> > fairly hard to avoid a situation in which the IETF and ISOC end
> > up with different positions on an issue with external visibility
> > and consequences.  To do so would damage the credibility of all
> > concerned.
> 
> This I completely agree with, we have to avoid such situations.
> 
> But we have to also to work hard on not to create a chicken out of
> a
> feather. Instead learn and do things even better next time.
> 
> Regarding Liberty Alliance, I think we should let Lucy coordinate
> some
> more information for the IETF that can be presented in due time. As
> she said, she will (as well as I) be in San Francisco and we are
> all
> happy to talk.
> 
> Patrik
> 
> -- next part --
> A non-text attachment was scrubbed...
> Name: PGP.sig
> Type: application/pgp-signature
> Size: 186 bytes
> Desc: This is a digitally signed message part
> Url :  archive/web/ietf/attachments/20090302/28633679/attachment.sig>
> 
> --
> 
> Message: 2
> Date: Mon, 2 Mar 2009 01:05:18 -0800
> From: "Tex Texin" 
> Subject: draft-ietf-ltru-4645bis-10.txt issue with preferred value
> for
>   YU
> To: ,  
> Message-ID: <005e01c99b16$0b00d700$210285...@com>
> Content-Type: text/plain; charset="utf-8"
> 
> With respect to the proposed update to the Language Subtag Registry
> draft-ietf-ltru-4645bis-10:
> 
> 
> 
> I would like to lodge an objection to the deletion of the
> Preferred-Value for language subtag YU.
> 
> 
> 
> This change breaks the equivalence class relation between YU and CS.
> It detrimentally changes the behavior of existing implementations.
> 
> The loss of the relationship between YU and CS makes documents that
> were believed to be tagged equivalently, to no longer be equivalent.
> 
> 
> 
> There is also no benefit to this change.
> 
> 
> 
> To be concrete, assume a user attempts to find documents for
> languages from Yugoslavia.
> 
> Using the then current registry data, a query tool noting the
> preferred value relationship, matches either xx-YU and xx-CS.
> 
> 
> 
> Another user searches for documents for Serbia.
> 
> A query tool using the current registry data noting the preferred
> value relationship, matches either xx-YU and xx-CS.
> 
> 
> 
> The results are in some sen

BCP 47 reference (was Re: Last Call: draft-nottingham-http-link-header from digest)

[Phillips, Addison]

Hello Mark,

> Regarding hreflang - looking through the history, it's been discussed  
> in a fairly positive light a few times, but never made it in. I think  
> it does make some sense, since it's both in Atom and HTML. 

I think hreflang would be useful to add. You might want to consider calling it 
just 'lang', since that locution is more familiar.

I think you might want to make it more than a single language tag. The purpose 
of http-link-header is to provide metadata about a link in addition to the URI. 
This is more like providing the author's intended target audience rather than 
the document processing language. That is, it's like the Content-Language 
header and/or  element, rather than like the  lang attribute. Cf. 
http://www.w3.org/International/questions/qa-http-and-lang#answer 

> I'm a bit  
> concerned about what the appropriate reference is for the value space;  
> ATM I'm thinking BCP47 directly, rather than to a specific RFC, to  
> allow it to evolve*.

Although there is a new RFC-to-be (4646bis) now in the RFC-editor's pipeline, I 
rather think that future changes to BCP 47 will tend to be limited to the 
production of extensions defined by 4646/4646bis, rather than changes to the 
grammar of language tags. There are some people who think that a revision might 
happen to use some reserved subtags for ISO 639-6 if/when that standard reaches 
maturity, so the possibility of revision does remain.

> ...
> * Often, a reference to an RFC is preferable, so that software can be  
> reliably written to a specific set of identifiers. My initial feeling  
> is that here that's not appropriate to do that, because language tags  
> are labels, not something that you're going to hardcode into  
> infrastructure software. Feedback appreciated, especially from the  
> i18n community.

Language tags are, as you note, labels that should not be hardcoded into 
infrastructure. However, BCP 47 defines the grammar for language tags 
themselves. Implementers need a reference to determine if the list of language 
tags they generate or receive is well-formed or not. That might be a good 
reason for a specific reference. Otherwise, I tend to recommend that people 
reference BCP 47 (it avoids that old chestnut "RFC WXYZ or its successor").

Best Regards,

Addison

Addison Phillips
Globalization Architect -- Lab126
Chair -- W3C Internationalization WG

Internationalization is not a feature.
It is an architecture.


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: BCP 47 reference (was Re: Last Call: draft-nottingham-http-link-header from digest)

[Phillips, Addison]

> Your proposal to use 'lang' to mean the same as @hreflang in HTML,
> when there is
> also a seperate @lang HTML, is confusing. I think it is probably
> best if this
> specification honours this historical distinction.

I don't disagree, which is why I said "consider". The problem with the 
historical usage is that people are confused by how to use it. They expect a 
'lang' refers to the language of the item in question.

Addison

Addison Phillips
Globalization Architect -- Lab126
Chair -- W3C Internationaliation WG

Internationalization is not a feature.
It is an architecture.


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-nottingham-http-link-header (from digest)

[Phillips, Addison]

Noah asked:

  * Is there a default encoding for parameter values, or in fact any other part
of this header. I could not find anything in the draft which would indicate
there is a default. Could this cause problems?

Mark specifies link in terms of IRI [RFC 3987], as well as specifying that the 
rules in RFC 3987 be used for mapping to URI when necessary. This, indeed, 
addresses this issue.

Regards,

Addison

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf