407938 - ko changes to web services for Firefox 3

Status: RESOLVED FIXED

(Mozilla Localizations :: ko / Korean, defect)

Description

[Channy Yun [:channy]]

It's for web services issue of Firefox 3 ko version.

1. Search plugins : Drop amazon.com for rare users in Koera and adding danawa.co.kr, the popular price comparison based search engine.

2. RSS feeds:  Drop bloglines and my yahoo.

3. New protocol handler: on discussion.

Comment 1

[Mic Berman]

adding rationale for changes from IRC discussion

new guidelines for commerce engines from discussion with Mike Beltzner are: engine should allow users to quickly find and complete transactions for new or used products. choosing the most popular auction, general shopping, or classified type sites are good choices. Good should be judged by a combination of popularity and desired user experience: getting you connected to thing want to buy as quickly and painlessly as possible in a "trusted" site. No more than 2 engines should be included.

in the case of Korea there is the activeX serious issue which means that most commerce sites are required to be activeX enabled making users unable to use Firefox to complete the transaction. Channy: "so searching goods is good functions to users."

Based on this (the above), the most popular and comprehensive site for searching for goods Channy recommended either auction.co.kr or danawa.co.kr. Based on some community feedback and a review of the sites we believe Danawa is more comprehensive and better user experience (results are clearer and many more). see comparator for xbox: 
http://search.danawa.com/dsearch.php?ut=0&k1=xbox&x=0&y=0
http://search.auction.co.kr/search/search.aspx?keyword=xbox&itemno=&seller=&dom=auction&isSuggestion=No&optSection=%C5%EB%C7%D5%B0%CB%BB%F6&txtKeyword=xbox&x=0&y=0

For RSS Readers, the guidelines are: in the local language and most popular among uses. Based on data of useage in market Channy suggested that bloglines and my yahoo are not widely used in Korea and that daum and hanrss are most popular and that while google is not most popular it's used by many firefox users so we recommend those 3.

for web calendar and webmail. following the same guidelines as for readers, the most popular we discussed are daum for webmail and gmail
and for calendar they could be: 
 http://calendar.daum.net and http://www.lifepod.co.kr

Comment 2

[Channy Yun [:channy]]

Attachment: danawa-kr.xml

It's pre-tested danawa-kr.xml by me.

Comment 3

[Axel Hecht [:Pike]]

The search plugin is using x-windows-949 as input encoding, the danawa site specifies EUC-KR, though. Not sure if there's a difference, smontagu?

Mic, do we have approval on the "from=firefox" search param that this would send?

Comment 4

[Simon Montagu :smontagu]

In theory x-windows-949 is a superset of EUC-KR. In practice we use the same decoder for both because many sites are labelled as EUC-KR but contain characters that are only in x-windows-949. See bug 131388, especially bug 131388 comment 31 and following.

Comment 5

[Mic Berman]

channy - re comment #3 - do you have a contact at danawa I can ping? thanks

Comment 6

[Channy Yun [:channy]]

(In reply to comment #5)
> channy - re comment #3 - do you have a contact at danawa I can ping? thanks
> 

I got a contact of Danawa, Seungsook Kang, [e-mail].
I contacted to her about addiong danawa plugin via email, but I didn't hear from her yet. I'll contact again via phone [phone] ext.134

Comment 7

[Channy Yun [:channy]]

Mic,

My community want to change search plugins for Firefox 3 as following.
1. Google
2. Yahoo
3. Naver
4. Daum
5. Danawa (replace of Amazon.com)
6. Wikipedia Korean (replace of CC)

Comment 8

[Mic Berman]

regarding replacing CC. Gen and others have indicated that keeping CC in is a good thing because of our shared general goals. If it's ok with you can we keep it in and have 7 plug ins?

Comment 9

[Mic Berman]

comment #6. I've sent Seungsook an email as well and given her a "negative option" to opt out of us using their service. As Danawa is a major provider in Korea and therefore should be able to handle our traffic, and because of the late stage close to release I thought this was the best way to proceed. I've never had anyone turn down our traffic before so I think we'd be safe. When she responds either way I'll post her response to this bug.

Comment 10

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 292639 [details]
danawa-kr.xml

Looks good to me.

Comment 11

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #8)
> regarding replacing CC. Gen and others have indicated that keeping CC in is a
> good thing because of our shared general goals. If it's ok with you can we keep
> it in and have 7 plug ins?

Sounds like a fine plan to me. Other locales also ship both CC and a localized Wikipedia plugin.

(Wasn't sure if your needs-gavin was for input on that comment, or just review of the existing plugin, so I provided both!).

Comment 12

[Gen Kanai [:gen]]

Let me second Mic's and Gavin's comments.  The CC plugin is a global default and we would prefer to keep it in unless there was a significant reason to delete it.

Comment 13

[Mic Berman]

channy, ping?

Comment 14

[Channy Yun [:channy]]

If CC is default, Gen is right. We just wanted to advocate Wikipedia Korean because of there were few contribution rather than CCK.  I'm not sure whether adding new one, seven plug-ins is good or not.

Comment 15

[Mic Berman]

Channy - 7 is ok

Comment 16

[:Gavin Sharp [email: [e-mail]]]

Looks like we need a patch that removes amazondotcom from list.txt, and adds the danawa plugin attached here.

Also need a patch to add Wikipedia Korean (based off of http://ko.wikipedia.org/w/opensearch_desc.php , presumably, but with added <SearchForm>http://ko.wikipedia.org/w/index.php?title=%ED%8A%B9%EC%88%98%EA%B8%B0%EB%8A%A5:Search</SearchForm> element and <InputEncoding>UTF-8</InputEncoding>).

Comment 17

[Axel Hecht [:Pike]]

Let's use http://mxr.mozilla.org/mozilla/source/browser/locales/en-US/searchplugins/wikipedia.xml as template, the ShortName should be "위키백과 (ko)", to match the link rel="search" title on ko.wikipedia.org.

Comment 18

[Channy Yun [:channy]]

Attachment: Wikipedia (Korean)

By Axel's recommendation, I uploaded new Wikipedia plugin for Korean version.

Comment 19

[Channy Yun [:channy]]

Attachment: new Daum-kr.xml plugin

By Bug 422250, I changed from .ico format to .gif base 64 in <Image>. Also I got notification from the search division of Daum. The url policy was
changed from http://search.daum.net/cgi-bin/nsp/search.cgi to
http://search.daum.net/search because of ban from some sites including
"cgi-bin".

Comment 20

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 309355 [details]
new Daum-kr.xml plugin

><Url type="text/html" method="GET" template="http://search.daum.net/search">
>  <Param name="q" value="{searchTerms}"/>
>  <Param name="w" value="tot"/>
>  <Param name="nil_ch" value="ffsr"/>
></Url>

r=me on the rest, but I can't vouch for the parameters being correct other than to verify that {searchTerms} is interpreted correctly. Have you checked with them? Do they want a Firefox-specific parameter? (Is that what nil_ch=ffsr is?)

Comment 21

[Channy Yun [:channy]]

(In reply to comment #20)
> (From update of attachment 309355 [details])
> ><Url type="text/html" method="GET" template="http://search.daum.net/search">
> >  <Param name="q" value="{searchTerms}"/>
> >  <Param name="w" value="tot"/>
> >  <Param name="nil_ch" value="ffsr"/>
> ></Url>
> 
> r=me on the rest, but I can't vouch for the parameters being correct other than
> to verify that {searchTerms} is interpreted correctly. Have you checked with
> them? Do they want a Firefox-specific parameter? (Is that what nil_ch=ffsr is?)
> 

Most of Korean search engines have unique characteristics to show all result in one page gathering all of section image, blog, news etc. "w=tot" means top search results. (c.f w=blog, w=news) And "nil_ch=ffsr" means Daum's own log parameter.

Comment 22

[Axel Hecht [:Pike]]

Please land the reviewed changes with a check-in comment referencing this bug, and gavin's review.

Could you forward the change request from daum on the search url to Mic? Or get an English version of it for her? Do we need to update the daum-kr plugin on the MOZILLA_1_8_BRANCH, too?

Comment 23

[Channy Yun [:channy]]

(In reply to comment #22)
> Please land the reviewed changes with a check-in comment referencing this bug, and gavin's review.

I forwarded Daum's request in english to Mic. And it must be effect to 1.8 branch too. (Daum will be offered old url by forwarding to new url in 6 months still.)

Do I have to file another bug for 1.8 branch? 

Comment 24

[Channy Yun [:channy]]

Attachment: list.txt patch

Comment 25

[Channy Yun [:channy]]

Would someone approve landing 1.9 trunk?

Comment 26

[Axel Hecht [:Pike]]

Attachments 292639, 309354, 309355 are already reviewed by gavin and ready for check-in. Nobody that can do the reviews actually has powers to grant approval1.9, we're just going for reviews right now.

Please check in with review comments referencing this bug and gavin's review, something like "bug 407938, replace amazon with danawa, add wikipedia, r=gavin" would work.

Please note that we're closing the tree for B5 today, Tuesday, 23:59 PST. If you can't make that, there will be another landing window after that.

Comment 27

[Axel Hecht [:Pike]]

Comment on attachment 310149 [details] [diff] [review]
list.txt patch

r=me on the change to list.txt.

This would be easier to review and manage if we got one patch for the whole thing.

Comment 28

[Channy Yun [:channy]]

Attachment: daum-kr.xml to be added suggest url

Daum also requested yesterday to add suggest URL. You can find suggest URL from http://top-sc.daum-img.net/w3c/OpenSearch.xml in daum.net.

URL is http://sug.search.daum.net/search_nsuggest?mod=fxjson&code=utf_in_out&q={searchTerms}.

Comment 29

[Channy Yun [:channy]]

Attachment: daum-kr.xml to be added suggest url

----
Daum also requested yesterday to add suggest URL. You can find suggest URL from
http://top-sc.daum-img.net/w3c/OpenSearch.xml in daum.net.

URL is
http://sug.search.daum.net/search_nsuggest?mod=fxjson&code=utf_in_out&q={searchTerms}.

Comment 30

[Channy Yun [:channy]]

Attachment: daum-kr.xml to be added suggest url

Adding suggest URL in Daum's search plugin. fixed URL to be valid XML format. My company omitted & in front of q={SearchTerm}.

Comment 31

[Channy Yun [:channy]]

Attachment: danawa-kr, daum-kr, wikipedia-kr, list.txt patch

All in one patch for danawa-kr, daum-kr, wikipedia-kr, list.txt.

Comment 32

[Axel Hecht [:Pike]]

Attachment: fix yahoo mail bustage in region.properties

This patch fixes a bustage in the yahoo mail settings. I just landed this in cvs, attaching patch here for reference.

Please update your working copies.

Comment 33

[Channy Yun [:channy]]

Attachment: Change Daum's encoding and Add Naver's suggest URL.

As I mailed to Mic, Axel, Naver requested to add their own URL. And Daum also request their encoding from x-windows-949 to utf-8 because of supporting unicode-based search.

Comment 34

[Axel Hecht [:Pike]]

Comment on attachment 310446 [details] [diff] [review]
Change Daum's encoding and Add Naver's suggest URL. 

I'd like to get a version with <Param> elements for naver-kr's suggest url, those are easier to read.

Is daum doing some kind of heuristic to figure out whether we're sending x-windows-949 or utf-8, or is there an additional search key we need to set for that?

A nit, could you do the diffs with -u,
cvs -z3 diff -u
that's the common diff format we use, and thus we can read it more fluently. Thanks.

Comment 35

[Mic Berman]

per comment #33, email received thanks

Comment 36

[Channy Yun [:channy]]

Attachment: Change Daum's encoding and Add Naver's suggest URL.

1)  I changed suggest's GET parameters to <Param> both daum-kr.xml and naver-kr.xml
2)  I changed from x-windows-949 to utf-8 because Daum supports utf-8 encoding and only support utf-8 in suggest.
3)  I changed utf-8 encoding from wrong encoding ANSI-DOS for daum-kr.xml
4) I made a diff with  "cvs -z3 diff -u"

Comment 37

[Axel Hecht [:Pike]]

Comment on attachment 310450 [details] [diff] [review]
 Change Daum's encoding and Add Naver's suggest URL.

r=me, please land with a good comment again.

Comment 38

[Channy Yun [:channy]]

(In reply to comment #37)
> (From update of attachment 310450 [details] [diff] [review])
> r=me, please land with a good comment again.
> 

It was committed. Thanks for your review. (Locking is delayed for a day.^.^)

Comment 39

[kwon se]

Attachment: naver searchplugins for suggest

Comment 40

[Axel Hecht [:Pike]]

kwon se, channy, I see a change request for naver's autocomplete url to change the host from rtquery.search.naver.com to ac.search.naver.com. Is that right?

Comparing 

http://rtquery.search.naver.com/autocompl?m=s&ie=utf-8&q=te with
http://ac.search.naver.com/autocompl?m=s&ie=utf-8&q=te

looks ok, but

http://rtquery.search.naver.com/autocompl?m=s&ie=utf-8&q=%EB%AA%A8%EC%A7%88
vs
http://ac.search.naver.com/autocompl?m=s&ie=utf-8&q=%EB%AA%A8%EC%A7%88

yields to no results for ac.s.n.c.

Is that a bug or intentional?

Comment 41

[Axel Hecht [:Pike]]

Oh, did we get to any resolution here on mailto: and webcal:?

Comment 42

[Mic Berman]

Channy from original description of this bug

the most popular we discussed are daum for webmail and gmail
and for calendar they could be: 
 http://calendar.daum.net and http://www.lifepod.co.kr

I have not contacted these folks yet :( to enable this so will do so now and get back to you all. Channy can you handle contacting daum on calendar and mailto fronts? Also can you get me a contact from lifepod I can't figure out where on their site I can get that

thanks

Comment 43

[Channy Yun [:channy]]

(In reply to comment #42)
> Channy can you handle contacting daum on calendar and
> mailto fronts? Also can you get me a contact from lifepod I can't figure out
> where on their site I can get that

In case of 30boxes, it just show all schedules from ICS url. I guess it's hard to implement in short time. Although Daum calendar has exporting ics, it's another problem whether they open calendar interface or not. I'll contact to them in Korean communication. And is there default as like google calendar except 30boxes? 

In case of webmail, i just noticed mailto protocol handler to them. hanmail and naver are big local providers. Are hotmail, gmail and yahoo included in default?

Comment 44

[Mic Berman]

for webcal and mailto for defaults we have been tracking these in bug 413630 There has been a problem with 3d party providers understanding our documentation and what we really require to enable the protocols but this has been (or should be) fixed now. Because of this, we are going to miss shipping with Google Mail or Google Calendar for Firefox 3.0. We may miss Hotmail all together (hoping to fix that). We currently have Yahoo mailto (although there are some problems). And 30boxes should be working for webcal. Google will be shipped in 3.0.0.1 version and updated for L10n in that release too (that's the plan).
So, please contact Naver and Hanmail. It would be great to have local options landed for Fx3.0 release. Here are the instructions to send them to 
http://developer.mozilla.org/en/docs/Web-based_protocol_handlers
for more information and contact me ASAP by email or on IRC for any questions.

Comment 45

[Channy Yun [:channy]]

(In reply to comment #40)
> Is that a bug or intentional?

Mr. Kwon se reply to me that he fixed your problem and noticed to me that rtquery server will be replaced ac server for suggest.

I'll checked in Kwon's xml file to repository.

Comment 46

[Axel Hecht [:Pike]]

(In reply to comment #45)
> (In reply to comment #40)
> > Is that a bug or intentional?
> 
> Mr. Kwon se reply to me that he fixed your problem and noticed to me that
> rtquery server will be replaced ac server for suggest.
> 
> I'll checked in Kwon's xml file to repository.
> 

So, first of all, please don't check in changes to search without review. Secondly, I'm still confused which server is going to be the long term solution for naver, ac or rtquery? Thirdly, you didn't check in Kwon's version for naver suggest, but yours.

I'm happy to see that the two servers return the same results now, but we still need a consistent story on what's supposed to be implemented.

Comment 47

[kwon se]

(In reply to comment #46)
> (In reply to comment #45)
> > (In reply to comment #40)
> > > Is that a bug or intentional?
> > 
> > Mr. Kwon se reply to me that he fixed your problem and noticed to me that
> > rtquery server will be replaced ac server for suggest.
> > 
> > I'll checked in Kwon's xml file to repository.
> > 
> So, first of all, please don't check in changes to search without review.
> Secondly, I'm still confused which server is going to be the long term solution
> for naver, ac or rtquery? Thirdly, you didn't check in Kwon's version for naver
> suggest, but yours.
> I'm happy to see that the two servers return the same results now, but we still
> need a consistent story on what's supposed to be implemented.

Current naver's suggest is rtquery server.
But domain and server will be changed ac server (in progress)
so two servers return the same results :)

consequently, domain ac is right solution for naver


as you know, rtquery and ac return same result.

Comment 48

[Channy Yun [:channy]]

(In reply to comment #44)
> So, please contact Naver and Hanmail. It would be great to have local options
> landed for Fx3.0 release.

For web mail handler in Korean version,

I got reply from naver mail. Mr. Jungil Park([e-mail]) is contact point. He let me know as following implementation.
http://mail.naver.com/write/?cmd=compose&to=[e-mail]&subject=test 

Also Hyukjoong Jang <[e-mail]> is hanmail's contact. He let me know that function will be implemented unitl April, 18th.

Comment 49

[Axel Hecht [:Pike]]

So we need a patch to change rtquery to ac for the naver plugin.

Could someone get back to Mr Jungil Park and forward that the URL we'd be loading would be

http://mail.naver.com/write/?cmd=compose&to=mailto%3Asneezer%40nhncorp.com%26subject%3Dtest

i.e., that the replaced value is the complete mailto URL, after encodeURIComponent. We're sending the URL as is, so we're not doing any conformance checks on whether that URL is conforming with the mailto: RFC or not either. More details on http://developer.mozilla.org/en/docs/Web-based_protocol_handlers.

Regarding hanmail, April 18th is likely too late for Firefox 3.0, but we'll be happy to take further providers on board on Firefox 3.0.1 and beyond. Note that the providers themselves can add the javascript on their site to add their API for their users, too, as detailed in above documentation.

Comment 50

[Axel Hecht [:Pike]]

PS: We'd really prefer an https link for mailto urls. Which, in the case of Korea, might be an odd-sounding request, but still.

Comment 51

[Channy Yun [:channy]]

(In reply to comment #49)
> So we need a patch to change rtquery to ac for the naver plugin.

Now I discussed with all of search providers for "ShortName" from english to korean e.g. "Naver" to "네이버" by each company's brand guideline. After that, I'll make patch.

> Could someone get back to Mr Jungil Park and forward that the URL we'd be
> loading would be
> 
> http://mail.naver.com/write/?cmd=compose&to=mailto%3Asneezer%40nhncorp.com%26subject%3Dtest

In case of Yahoo!Mail, there is still error. they didn't escape mailto: string and Yahoo! ajax version is not supported this function in beta 5. :) Anyway I'll let him know.

Comment 52

[Axel Hecht [:Pike]]

The yahoo issue is known, and at least for the ajax version is waiting for deployment.

For the ShortNames, that should be cool, but we need to make a call on that quickly.

Comment 53

[Mic Berman]

comment #49, i will let mr. park know

Comment 54

[Jungil Park]

Hello~~ :)

(In reply to comment #49)
> So we need a patch to change rtquery to ac for the naver plugin.
> Could someone get back to Mr Jungil Park and forward that the URL we'd be
> loading would be
> http://mail.naver.com/write/?cmd=compose&to=mailto%3Asneezer%40nhncorp.com%26subject%3Dtest

This query consists of 'to' and 'subject'. It's not one. 

1. http://mail.naver.com/write/?cmd=compose&to={RECEIVER EMAIL}
2. http://mail.naver.com/write/?cmd=compose&to={RECEIVER EMAIL}&subject={MAIL SUBJECT}

'subject' is optional.

e.g. When you send email to '[e-mail]' using the NAVER MAIL, you have to write
  => http://mail.naver.com/write/?cmd=compose&to=[e-mail]
 
> i.e., that the replaced value is the complete mailto URL, after
> encodeURIComponent. We're sending the URL as is, so we're not doing any
> conformance checks on whether that URL is conforming with the mailto: RFC or
> not either. More details on
> http://developer.mozilla.org/en/docs/Web-based_protocol_handlers.
> Regarding hanmail, April 18th is likely too late for Firefox 3.0, but we'll be
> happy to take further providers on board on Firefox 3.0.1 and beyond. Note that
> the providers themselves can add the javascript on their site to add their API
> for their users, too, as detailed in above documentation.

Comment 55

[Mic Berman]

per comment #54. the way you describe the url and query above is different from how we would like things to work as described in the link above and more specifically when you read that link: "the server side code is passed the entire contents of the href. This means the server side code will have to parse out the protocol from the data" copying this bug to Mark Finkle for further explanation

Comment 56

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to comment #54)
> > Could someone get back to Mr Jungil Park and forward that the URL we'd be
> > loading would be
> > http://mail.naver.com/write/?cmd=compose&to=mailto%3Asneezer%40nhncorp.com%26subject%3Dtest
> 
> This query consists of 'to' and 'subject'. It's not one. 
> 
> 1. http://mail.naver.com/write/?cmd=compose&to={RECEIVER EMAIL}
> 2. http://mail.naver.com/write/?cmd=compose&to={RECEIVER EMAIL}&subject={MAIL
> SUBJECT}
> 
> 'subject' is optional.
> 
> e.g. When you send email to '[e-mail]' using the NAVER MAIL, you have to
> write
>   => http://mail.naver.com/write/?cmd=compose&to=[e-mail]
> 

Jungil - It doesn't work that way. Web protocol handlers really don't know the details of the protocol itself. For example, in the case of a mailto: link

<a href="mailto:[e-mail]">Webmaster</a>

Firefox has no idea about the specifications of the mailto: protocol, so Firefox can't break apart the pieces of the HREF ( "[e-mail]" in this case). Therefore, Firefox sends the entire HREF ("mailto:[e-mail]") to the server-side handler URL ("http://mail.naver.com/write/?cmd=compose&to=mailto:[e-mail]")

Obviously, this is not what you are expecting, but it is the way web protocol handlers work in Firefox 3.

So, to make this work, you need to add code in your server-side handler to parse out the parts of the protocol. Also, see this page for more information about how web protocol handlers work:
http://developer.mozilla.org/en/docs/Web-based_protocol_handlers

Comment 57

[Jungil Park]

(In reply to comment #56)
> (In reply to comment #54)
> > > Could someone get back to Mr Jungil Park and forward that the URL we'd be
> > > loading would be
> > > http://mail.naver.com/write/?cmd=compose&to=mailto%3Asneezer%40nhncorp.com%26subject%3Dtest
> > 
> > This query consists of 'to' and 'subject'. It's not one. 
> > 
> > 1. http://mail.naver.com/write/?cmd=compose&to={RECEIVER EMAIL}
> > 2. http://mail.naver.com/write/?cmd=compose&to={RECEIVER EMAIL}&subject={MAIL
> > SUBJECT}
> > 
> > 'subject' is optional.
> > 
> > e.g. When you send email to '[e-mail]' using the NAVER MAIL, you have to
> > write
> >   => http://mail.naver.com/write/?cmd=compose&to=[e-mail]
> > 
> Jungil - It doesn't work that way. Web protocol handlers really don't know the
> details of the protocol itself. For example, in the case of a mailto: link
> <a href="mailto:[e-mail]">Webmaster</a>
> Firefox has no idea about the specifications of the mailto: protocol, so
> Firefox can't break apart the pieces of the HREF ( "[e-mail]" in this
> case). Therefore, Firefox sends the entire HREF ("mailto:[e-mail]") to
> the server-side handler URL
> ("http://mail.naver.com/write/?cmd=compose&to=mailto:[e-mail]")

I understand. I modified the server-side code as you wish. 

> Obviously, this is not what you are expecting, but it is the way web protocol
> handlers work in Firefox 3.
> So, to make this work, you need to add code in your server-side handler to
> parse out the parts of the protocol. Also, see this page for more information
> about how web protocol handlers work:
> http://developer.mozilla.org/en/docs/Web-based_protocol_handlers

Comment 58

[Axel Hecht [:Pike]]

Patches missing for 

naver suggest url change

testing of mail.naver.com, if it works, a patch to implement that, and please remember to bump defaultHandlersVersion in that patch, too.

Comment 59

[Channy Yun [:channy]]

Attachment: Firefox 3 Korean search services - final patch

Firefox 3 Korean search service final patch.

1. ShortName of danawa, daum and naver are changed from english to korean. I got all feedback from them by rule of their brand guidelines. I'll forward to them to Mic.

2. Naver's new suggest server changes to ac.search.naver.com by #310948.

Please review it.

Comment 60

[Channy Yun [:channy]]

Mic, Axel. 

There is one thing to be changed in RSS reader of Firefox 2 and Firefox 3. Daum RSS will be changed to from http://rss.daum.net/rssplus/myhome/ShowInsertUserChannelForm.do?channelUrl=%s
 to http://blog.daum.net/_blog/rss/ChannelInsertDirect.do?channelUrl=%s. 
(Must I file another bug for Firefox 2.0.0.15?)

Comment 61

[Mic Berman]

channy - we're running out of time as you know. we have 24 hours basically to get any final changes in. it's difficult to track what changes are happening and why to the daum and naver search specifics like parameters etc. for comment #59 can you explain exactly what they changed and why. ping me on IRC for any questions

Comment 62

[Mic Berman]

per patch in comment #59, this is source for change: 

----- Original Message -----
From: "Channy Yun" 
To: "Michal Berman", "Axel Hecht" 
Sent: Wednesday, March 19, 2008 7:42:00 AM GMT -05:00 US/Canada Eastern
Subject: Fw: adding naver's suggest.

Mic, Axel. 

NHN, Naver search's owner request to add suggest URL in their search plugin. 
I'll make patch for it. 

Channy 


---------- Forwarded message ---------- 
From: 권세 < kwonse > 
Date: 2008/3/19 
Subject: RE: FW: Firefox 검색 플러그인 기능 확장 
To: channy 

안녕하세요 . 

nhn 통합검색서비스개발팀 권세입니다 . 

아래와 관련해서 naver-kr.xml 파일에 자동완성과 관련된 내용들이 추가될 텐데요 . 

이 부분에 대한 내용을 저희쪽에서 정리해서 보내드리는 것이 맞는지요 ? 

또한 초기에 NAVER TOP 페이지에도 아래와 같이 추가 하기로 했던 것 같은데 .. 현재는 존재하지 않습니다 . 이 부분도 확인해야 할 듯합니다 . 

<link rel="search" type="application/opensearchdescription+xml" href=" http://sstatic.naver.com/search/opensearch-description.xml " title="Naver" /> 

Mozila 측에 naver-kr.xml 의 설정중 자동완성 부분을 추가 요청해야 할 듯합니다 . 

<Url type="application/x-suggestions+json" method="GET" template=" http://rtquery.search.naver.com/autocompl?m=s&ie={inputEncoding}&q={searchTerms} " /> 


권순선 (Shawn Kwon) 
NHN Open Technology T/F 

Comment 63

[Mic Berman]

also for patch in comment #59, here is confirmation of permissions etc.


----- Original Message -----
From: "Channy Yun" 
To: "Michal Berman" 
Sent: Tuesday, April 8, 2008 3:44:12 PM GMT -05:00 US/Canada Eastern
Subject: Fwd: ShortName change for Firefox 3 Ko version

Dear Mic, 

I got as following acceptance mail from NHN. 
In case of Daum, I guaranteed about brand change as a result of inquiry to brand department. 
In case of Danawa, you can see brand guideline to accept both english and korean in http://www.danawa.com/corp/prcenter/ci.html?left=3 

Channy 


---------- Forwarded message ---------- 
From: 권순선 < kss > 
Date: 2008/4/4 
Subject: RE: FW: Firefox 검색 플러그인 기능 확장 
To: 권세 < kwonse >, channy 
Cc: channy, 박영광 < glory >, 장규범 < issiksik > 

저희 브랜드 가이드를 확인해 보았는데 

' 네이버 ' 도 문제 없습니다 . 

석찬님 , 말씀하신 대로 진행하셔도 무방합니다 . ^^ 

----------------------------- 

권순선 (Shawn Kwon) 
NHN Open Technology T/F 

Comment 64

[Channy Yun [:channy]]

1) ShortName changes.
I suggested shortName changes for Korean users easy to find local search engine in search plugin by comment #51. Wikipedia's already in Korean. Naver,Daum and Danawa let me know there is no problem to change ShortName comment #63.

2) Naver parameter changes.
Naver's contact already uploaded own naver-kr.xml file via attachment #310948 [details]. My patch contained naver's directly with ShortName change. Mr. Kwon Se of NHN explained rtquery server will be go to ac server for suggest via comment #47.

Comment 65

[Channy Yun [:channy]]

Axel, Mic,

I got as following Hanmail's mailto handler URL and Naver's http://mail.naver.com/write/?cmd=compose&to=mailto%3Asneezer%40nhncorp.com%26subject%3Dtest also is working. I tested them in my account right now.

Channy

---------- Forwarded message ----------
From: 장혁중 <[e-mail]>
Date: 2008/4/9
Subject: RE: Re: Re: Firefox 3 mailto 서비스 관련
To: [e-mail]


석찬님, 아래 URL 로 mailto: 프로토콜을 처리하도록 했습니다.

http://mail.daum.net/hanmail/Goto.daum?cmd=compose&value=mailto:[e-mail]
http://mail.daum.net/hanmail/Goto.daum?cmd=compose&value=mailto%3Apostmaster%40hanmail.net%26subject%3Asubj_string

Comment 66

[Channy Yun [:channy]]

Attachment: Firefox 3 Korean mailto: handler services - final patch

Naver and Daum's mailto handler services. I tested them comment #65.

Comment 67

[Mic Berman]

channy, from my perspective, that's great about mailto for Hanmail, Naver and Daum. I think you're one of the very few that will have these landed for Fx3. great. i leave it to axel to review. 

at one point we were talking about having Daum for webcal - is this still happening?

Comment 68

[Channy Yun [:channy]]

(In reply to comment #67)
> at one point we were talking about having Daum for webcal - is this still
> happening?

I didn't get a news from lifepod yet. Daum is already implementing now. How about getting URL in advance and test in late (at least within next week)?

Comment 69

[kwon se]

I heard that there are too many parameters in naver's search plugins xml file from channy
especially

<Url type="text/html" method="GET" template="http://search.naver.com/search.naver">
<Param name="where" value="nexearch" /> 
<Param name="frm" value="ff" /> 
<Param name="sm" value="oss" /> 
<Param name="ie" value="utf8" /> 
<Param name="query" value="{searchTerms}" /> 
</Url>

"where" means current user's location like
http://search.naver.com/search.naver?where=people&query=love
http://search.naver.com/search.naver?where=nexearch&query=love

"frm" means "from"

"sm" means "send method"
when a user invoke a search, "sm" explains user's send method like
http://search.naver.com/search.naver?sm=tab_jum&where=nexearch&query=apple (case click the tab)
http://search.naver.com/search.naver?sm=tab_hty&where=nexearch&query=apple (case click the search button)

"ie" means "input encoding"
"query" means "query":)


thanks

Comment 70

[Mic Berman]

re comment #68, channy let's move webcal for daum to another bug for later landing when they are ready. you can file the bug when you hear from them. ok?

Comment 71

[Axel Hecht [:Pike]]

kwon se, thank you for the explanations. I still have a question though, we currently have

where=j

in the engine, and there is a proposed change to 

where=nexearch

The two results are fairly similar, but not equal, and I don't know which is the right one.

Comment 72

[kwon se]

"nexearch" is a default "where" value
if where parameter is ommitted, search engine add the "where parameter is nexearch" internally

if you set where=j(not designated like "people", 'cafeblog") , naver search engine set the value where=nexearch, even though user couldn't see the value in the url line

where=j, where=nexearch results is not similar, just same~!!
but some results can be different through search engine status (like collection update)

to conclue, where=nexearch is right one for where parameter's value

thanks

Comment 73

[Axel Hecht [:Pike]]

Comment on attachment 314388 [details] [diff] [review]
Firefox 3 Korean search services - final patch

Thanks for the explanation.

Based on that, r=me on the search patch here. Please land it with a check-in comment referencing this bug and my review, and describing the change.

Comment 74

[Axel Hecht [:Pike]]

Comment on attachment 314450 [details] [diff] [review]
Firefox 3 Korean mailto: handler services - final patch

r- on this one, it's just a nit, but I want to be sure to get it right as the concept is messy.

When you change anything in gecko.handlerService.schemes compared to what some user might have, you need to bump the gecko.handlerService.defaultHandlersVersion to actually make firefox pick up the new defaults.

Please create a new patch with that additional change.

Comment 75

[Channy Yun [:channy]]

Attachment: Firefox 3 Korean mailto: handler services - final patch 2

I increased handlerVersion number from 1 to 2.

Comment 76

[Axel Hecht [:Pike]]

Comment on attachment 314549 [details] [diff] [review]
Firefox 3 Korean mailto: handler services - final patch 2

r=me, please check-in with a comment as described above.

Comment 77

[Channy Yun [:channy]]

I checked in above two patches in separate. This bug is almost ended. Thanks for Mic and Axel's tireless support. Take care of your health too.

Comment 78

[Axel Hecht [:Pike]]

Thanks to everybody here for your support in getting this fixed.

Marking as such, with reference http://hg.mozilla.org/users/axel_mozilla.com/l10n-src-verification/index.cgi/file/7696c9349ee3/reference/HEAD/ko/.

Comment 79

[Channy Yun [:channy]]

I got a new contact from Danawa.com 
SeHee Jeong, [e-mail] Manager of Marketing division.