[webkit-dev] Fwd: IDNA, IRI, HTML5 coordination

2009-09-18 Thread 신정식,
Hi,

I just thought that we want to keep our eyes on what's being done on these
fronts and give feedback if necessary.

Jungshik

-- Forwarded message --
From: Larry Masinter masin...@adobe.com
Date: 2009/9/16
Subject: IDNA, IRI, HTML5 coordination
To: public-...@w3.org public-...@w3.org


Goal: bring together and coordinate the definitions
of what is used for resource identification in the web and elsewhere
(IRIs as the evolution of URL, URI, IRI, HREF, Web Address, etc.)
within W3C, IETF and their specifications. See design goals below.

Goal of this message: lay out the concerned groups, start discussion
of process for coordination.

I've bcc'd everyone except the public-...@w3.org mailing list,
archive http://lists.w3.org/Archives/Public/public-iri/ as the
list proposed for discussion:


My suggestion for how to get all of these groups to coordinate
is to start an IETF working group with a charter to bring these
specifications into alignment. I can't think of any other process
which can accomplish the goal.

PLEASE, PLEASE: if you're going to post an opinion, please at least
cc public-...@w3.org and try to keep discussion there.

PLEASE: Separate 'process' issues (should there be a working group?
Who else needs to be involved? What's the timing and when?) from
technical issues.

Thanks,

Larry

=
(Incomplete) list of specifications, groups, chairs, editors:

HTTP:

[HTTPBIS-URI] HTTP URI scheme def in HTTPBIS draft:

http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-07#section-9.2
[HTTP-RFChttp://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-07#section-9.2%0A[HTTP-RFC]
current HTTP URI scheme definition
 in RFC 2616 http://tools.ietf.org/html/rfc2616#section-3.2.2
[HTTPBIS-WG http://tools.ietf.org/html/rfc2616#section-3.2.2%0A[HTTPBIS-WG]
IETF HTTPBIS working group
   charter: http://tools.ietf.org/wg/httpbis/charters
http://www.ietf.org/dyn/wg/charter/httpbis-charter.html
   mailing list: ietf-http...@w3.org,
 archives http://lists.w3.org/Archives/Public/ietf-http-wg/
   chair:   Mark Nottingham m...@mnot.net
   editors: Roy Fielding field...@gbiv.com,
Julian Reschke julian.resc...@greenbytes.de, (others)

IDNA:
[IDNABIS-*] definitions, policies, standards for how Internationalized
 Domain Names should be handled in Internet applications
 http://tools.ietf.org/html/draft-ietf-idnabis-defs/
[IDNABIS-WG]  IETF IDNABIS working group
 charter: http://www.ietf.org/dyn/wg/charter/idnabis-charter.html
 chair: Vint Cerf v...@google.com
 editor: John C Klensin klen...@jck.com

IRI:
[IRIBIS-6] Revision under preparation:
 http://tools.ietf.org/html/draft-duerst-iri-bis-06
[IRIBIS-LMMhttp://tools.ietf.org/html/draft-duerst-iri-bis-06%0A[IRIBIS-LMM]
(Experimental draft attempting to satisfy IDNABIS and HTML requirements)
 http://larry.masinter.net/iribis-hack.html
 (
http://tools.ietf.org/rfcdiff?url1=draft-duerst-iri-bis.txturl2=http://larry.masinter.net/iribis-hack.txt
)
discussion on: public-...@w3.org (among others)
(other)editors: Martin Dürst due...@it.aoyama.ac.jp
Michel SUIGNARD mic...@suignard.com

Mailto URI:

[MAILTO-RFC] Mailto: URI scheme
 Current: http://tools.ietf.org/html/rfc2368
[MAILTO-BIS http://tools.ietf.org/html/rfc2368%0A[MAILTO-BIS] In
preparation
http://tools.ietf.org/html/draft-duerst-mailto-bis-06
  (other) editors (including) Martin Dürst (due...@it.aoyama.ac.jp)
  discussion on: u...@w3.org

URI:

[URI-RFC] URI spec
 http://tools.ietf.org/html/rfc3986
  mailing list: u...@w3.org
  (other) editors: Roy Fielding field...@gbiv.com, Tim Berners-Lee 
ti...@w3.org
[URIREG-RFC]
 URI guidelines: policies and procedures for registering new URI schemes
 http://tools.ietf.org/html/rfc4395
editors: Tony Hansen t...@att.com
mailing list for URI review: uri-rev...@ietf.org

HTML5:
[HTML5-CURRENT]   HTML5 definition of URLs
http://dev.w3.org/html5/spec/Overview.html#urls
[WEBADDRESS] Attempt to split out Web Address component:
http://www.w3.org/html/wg/href/draft
[HTML-WG http://www.w3.org/html/wg/href/draft%0A[HTML-WG] W3C Working
Group
charter: http://www.w3.org/html/wg/
URL/IRI issue: http://www.w3.org/html/wg/tracker/issues/56
chairs: Paul Cotton paul.cot...@microsoft.com
Maciej Stachowiak m...@apple.com
Sam Ruby ru...@intertwingly.net
editor: Ian Hickson i...@hixie.ch


Other interested groups:

IETF Applications area
 mailing list: apps-disc...@ietf.org
 area directors: Lisa Dusseault lisa.dussea...@gmail.com;
 Alexey Melnikov alexey.melni...@isode.com

W3C TAG (architectural issue around URIs in W3C specs)
mailing list: www-...@w3.org
archive http://lists.w3.org/Archives/Public/www-tag/
issue: http://www.w3.org/2001/tag/group/track/issues/27
chair: Noah Mendelsohn noah_mendels...@us.ibm.com

[WHATWG]  http://www.whatwg.org/


(Have I missed any 

Re: [webkit-dev] exposing the value of Accept-Language via window.navigation.acceptLanguage ?

2009-07-23 Thread 신정식,
Thank you all for the comments.

I'll write to whatwg and public-html about adding it to
window.navigator (yes, I meant navigator :-)) ).

2009/7/22 Alexey Proskuryakov a...@webkit.org:

 22.07.2009, в 22:36, Darin Fisher написал(а):

 Firefox and Chrome send very similar A-L headers.  Given FF's marketshare,
 I'm surprised you observed compat problems with doing the same.  Was that a
 recent observation?  Can you provide more details about the issues you
 observed?

Thank you for the reference.

 It's not recent, see http://lists.macosforge.org/pipermail/webkit-dev/2005-June/000217.html.


Most of pages (Netscape directory server?) referred to there are not
available any more. http://gun.teipir.gr/ds/csearch is still up and
fails in Chrome, Firefox 3, and IE 8 because they all send
Accept-Language with q-values.

The page I got back from the server in Firefox and Chrome is 'funny':

0 0. ko 1 0.7998 en_us 2 0.4997 zh 3 0.2996 en 0 0. ko 1
0.7998 en_us 2 0.4997 zh 3 0.2996 en

A-L sent was

ko,en-us;q=0.8,zh;q=0.5,en;q=0.3

(IE8 'fails' to load the page, too, but it just shows an HTTP error message).

 There is also some discussion in
 https://bugs.webkit.org/show_bug.cgi?id=3510, not sure if any of it is
 still relevant.
 I do not have a reference handy, but IIRC, sending quality values was
 breaking some widely deployed intranet webmail system.

https://bugs.webkit.org/show_bug.cgi?id=3510#c2 has a reference to
Outlook Webaccess, but that's about 'ru-ru' vs 'ru'.

There's a bug report against Chrome about an 'opposite' case. We used
to send languages without a q-value (which means everything gets
q=1.0). See http://crbug.com/3970  Safari should just work for this
case, though because the page in question works when only a single
language is sent with no q-value.


 It should be noted that normally people only have one value (or one family
 of values: en and en-US for example) on the A-L list, and that they have
 to configure their browser to advertise other languages.  I think that
 addresses the privacy concerns, assuming suitable wording in the
 configuration panel.

Yes, I agree.


 Safari takes the languages from system configuration.

Aha.. right. I forgot that when I wrote the first email in the thread.

Jungshik
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


[webkit-dev] exposing the value of Accept-Language via window.navigation.acceptLanguage ?

2009-07-22 Thread 신정식,
Hi,

 I proposed exposing the values of the Accept-Langauge  list via
window.navigation.acceptLanguages at

  https://bugs.webkit.org/show_bug.cgi?id=27555

This email is to get opinions (for and against) on that in case the
bug is not noticed by many. As pointed out by ap in the bug, perhaps,
we have to bring this up in the WHATWG as well. Before I do that, it
may not be a bad idea to know what others her think about it.

Currently, the UI language of a browser is exposed with
window.navigation.language.  This can be used by a 'web application' /
widget / browser extension to 'behave differently' per the UI
language.

A lot of web servers also take into account the value of
Accept-Language HTTP header field when determining the UI language of
their web apps or the language of contents to serve when multiple
language versions exist.  Moreover, most browsers (Safari, Chrome,
Firefox, IE, and so forth) allow users to add, delete, move up and
down a language to the prioritized list of languages they understand

Some web apps/widgets/browser extensions can also benefit from knowing
the ordered list of languages in Accept-Language.

One particular use case Chrome has in mind is to determine the target
language of translation without a user-intervention.  If the source
language is A and the A-L list has {B, C, D}, the target language can
be determined by walking through the list and picking up the first
language for which the translation from A is available. If 'A' is in
the A-L list, perhaps the translation service should not be called.  (
See http://crbug.com/14574 )

There might be other cases of 'multi-lingual' applications where the
knowledge of the A-L list can be helpful.


It can be exposed by adding either of the two below to window.navigation

 readonly attribute DOMStringList acceptLanguages // a list of
language codes

 readonly attribute DOMString acceptLanguages // a comma separated
language codes

Unlike in the Accept-Language http header field, a language in the
list will not have a q-factor associated with it. Instead, they're
sorted in the descending order of the priority.


Any opinion would be welcome.

Jungshik
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] currently failing regression tests on Mac OS X Leopard

2009-03-06 Thread 신정식,
Oops. I meant reply-to-all but just replied to Darin.

2009/3/6 Jungshik Shin (신정식, 申政湜) js...@chromium.org



 2009/3/6 Darin Adler da...@apple.com

 On Mar 6, 2009, at 8:36 AM, Dimitri Glazkov wrote:

  Since I checked in the failing tests, I feel responsible, too.

 I'd say let's remove these tests and work to get the CSS2.1 suite
 updated. WDYT?


 I think it's an acceptable strategy to have these new separate tests. I
 just think someone needs to generate the correct expected results.

 Changing the CSS 2.1 suite itself would be OK, but I don't think it would
 have a big effect. We'd still need correct expected results.


 Sorry for all the confusion. I mentioned the following on  IRC and in the
 bug, but perhaps, I was not clear enough.

 What happened  was that test results are correct, but actual test files
 (html files) that were svn-copied to a new location were NOT revised in the
 new place. (my patch has new html files, but during the landing, svn-apply
 did not work as intended and svn-copied files without actual changes went
 int).
 As a result, there's a mismatch between the expected result and what's
 supposed to be new test files (that ARE actually just the copies of the
 original tests).

 So, we can do any of the following (I'm also replying to Darin's question
 here).

 1. What Dave suggested on IRC.

 1a. Revise the original CSS 2.1 tests in place and remove what's added
 recently.
(this will be done by landing the latest patch in bug 23482)

 1b. Same end result as 1a:
- roll out what's added recently right away without waiting for
 Dave's r+.
- once Dave gives me a nod for in-place modification of the original
 tests, make that change.

 2. Leave the original tests alone and just update 'new' test html files in
 fast/block/float to match expected results.

 If we do 1a/1b,  I'm willing to talk to Ian once more about our changes and
 talk him into revising CSS 2.1 suite the same way. I already asked him in
 the bugzilla, but he may have missed it.

 #2 was what was agreed upon and what my second latest patch does, but
 yesterday, Dave said that it's better to revise the original tests in place.
 So, I made the latest patch (3rd patch in the bug) and asked him for
 review.

 Jungshik








 I think the main question is who will generate expected results that are
 correct for Mac OS X.

-- Darin



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev