Nicolas Williams | 1 Apr 2009 01:06
Picon

Re: supposing one would want to create a new URN space for timezones...

On Tue, Mar 31, 2009 at 06:54:30PM -0400, Cyrus Daboo wrote:
> Hi Nicolas,
> 
> --On March 31, 2009 5:33:18 PM -0500 Nicolas Williams 
> <Nicolas.Williams <at> sun.com> wrote:
> 
> >Face it: we need a registry.  And: we need country authorities to
> >participate.  That means we need to ask ISO for a solution.  Q.E.D.  :)
> 
> I disagree that authorities should have anything to do with this. We will 
> never get governments etc all on board with this. As I recall Pete Resnick 
> mentioned he had tried something like this in the past and failed.

ISO does get things done.  Slowly, perhaps, but we (the IETF) are not
necessarily much faster.  I realize that Pete Resnick is one of the
liasons to the ISO, but ISTM that Allison Mankin is the relevant liason
here (please correct me if I'm wrong!).  If Peter and Allison say "forget
asking the ISO," fine.

> The most important thing we need is a standard set of identifiers that are 
> guaranteed to refer to the same timezone definitions (rules, offsets etc). 

Great.  How does one "refer to the same timezone definitions"?  Where
are those?  I don't see how to escape the need for a registry.  Sorry.

> That is the key thing needed for interoperability across calendaring and 
> scheduling systems.

I agree with this.
(Continue reading)

Cyrus Daboo | 1 Apr 2009 02:34
Favicon

Re: supposing one would want to create a new URN space for timezones...

Hi Nicolas,

--On March 31, 2009 6:06:40 PM -0500 Nicolas Williams 
<Nicolas.Williams <at> sun.com> wrote:

>> The most important thing we need is a standard set of identifiers that
>> are  guaranteed to refer to the same timezone definitions (rules,
>> offsets etc).
>
> Great.  How does one "refer to the same timezone definitions"?  Where
> are those?  I don't see how to escape the need for a registry.  Sorry.

What is being proposed is a registry and a service. The registry defines 
the standard set of names that allow "consumers" to interoperate. 
"consumers" get matching timezone definitions by asking their "provider" 
(offering a timezone service) to return the data to them. "providers" get 
their data from one or more "publishers", optionally adding useful 
meta-data (who the publisher is, what version of data they have, geo 
information, whatever). The service takes care of handling updates to 
changes in the data. "publishers" get their data in whatever way is 
appropriate for them. In the case of an Olson style service, that would 
involve "contributors" spotting local changes to timezone definitions and 
posting those back to the publisher to incorporate into their data.

As Elliot has noted on several occasions, the way Olson works right now is 
pretty good. Some things need to be tweaked: guaranteed longevity of 
service, digital signatures on the data etc.

The goal here is not to put the data into the registry, just the names. 
Given that this is an internet-wide service, a typical registrar (e.g. 
(Continue reading)

zhangguoqiang | 1 Apr 2009 05:16
Picon

Solicitation for a discussion on Keyword-based addressing

 
Keyword service is thriving in non-english speaking countries these days, e.g, Netpia and digitalnames in Korea, CNNIC in China, JWORD in Japan. Even in U.S, there were realnames and netword. It proves to be a useful application both to end users and to advertisers.

However, the current keyword service each has its own solution, and lacks of coordination. For example, when a korean comes to China, then without plugin, he will unable to access the Korea keyword service.
 
When talking about keyword, most people will question its relationship with search engines and IDN. So, let me first clarify it here. Different from search engines, keyword-based addressing is an addressing technology. Based on whether a keyword is registered or not, the resolution result is determinstic for any given keyword, while the search for a keyword in a search engine is undetermistic, strongly depending on the search engine used and the exact time the search carried out.  Several features have made keyword-based addressing distinct from IDN. First, keyword maps to URL, which means it can be used to directly access a particular webpage, while IDN is used to access a web site. Second, keyword eases user's experience by eliminating the need to remember potentially great number of suffixes. This feature also provides a better way for advertisers to protect their brand names. Finally, orginating from the western countries, domain names inherit the input conventions from west countries, e.g, put the most signicant part into the rightmost, while our proposed keyword-based addressing can respect different input conventions.     
 
Surely, keyword-based addressing is not intended to replace IDN, search engine or URI. It is only a complenmentary technology. There are some usage scenarios where the keyword-based addressing is more effective than other techniques. For example, if you are a blogger of a portal blog website, typically, you are assigned a URL that identifies your blog. It is usually composed of two parts: a domain name and an ID(typically a magic number). So how can you advertise your blog to your friends? Use search engines? No, because your blog is not so popular. Use URL? It is too hard for people to remember. In this scenario, keyword-based addressing provides an effective way to access your blog, e.g. yahooblog:bob.
 
So, we think keyword-based addressing is a very useful technique, especially for non-english speaking countries. Even for english speaking countries, the above example also illustrates its practicability. To internationalize this service and provide cross resolution capability, we highly recommend a standard being developped.
 
Our keyword-based addressing draft is available at http://tools.ietf.org/html/draft-zhang-keyword-ddds-00, which specifies keyword-based addressing as a DDDS application.
 
In summary, our keyword addressing has the following advantages:
(1) simple syntax
(2) allows for global resolution
(3) repects cultural input conventions, the customized rules stored in DDDS database is responsible for the keyword-to-domanname tranlation.
(4) can be used for different applications
 
So, my solicitation is for a discussion of this draft or the keyword service itself. To my opinion, application area is the right place for this discussion.
 
2009-04-01
zhangguoqiang
Attachment (张国强(1).vcf): text/x-vcard, 286 bytes
_______________________________________________
Apps-Discuss mailing list
Apps-Discuss <at> ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss
SJ Kissane | 1 Apr 2009 05:48
Picon

Re: supposing one would want to create a new URN space for timezones...

Hi all

Wow this thread is long, I don't have time to read it all, but let me add my own two cents.

Unicode CLDR (http://cldr.unicode.org/) already defines unique identifiers for timezones,
which are the Olson names, save that as I understand, they only use the first name ever
defined, so if the name ever changes in Olson, they stick to the original name.
(see UTS#35 section 5.9.2 -- http://www.unicode.org/reports/tr35/#Timezone_Names)

It defines timezone names in multiple languages, mapping to pre-existing vendor
standards (i.e. Windows) -- I think it would be silly for IETF to reinvent the wheel
when the Unicode consortium are doing so much already in this area.

The point of a URN is to have a unique identifier, not every possible identifier you'd want to use.
So I'd say, use the CLDR identifier in the URN -- and then use a database like CLDR
to map those URN values to names in various languages to display to user,
or to map to vendor standards like Microsoft Windows, or so on.

Simon Kissane

_______________________________________________
Apps-Discuss mailing list
Apps-Discuss <at> ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss
Keith Moore | 1 Apr 2009 07:18
Picon

Re: supposing one would want to create a new URN space for timezones...

Nicolas Williams wrote:
Face it: we need a registry. And: we need country authorities to participate. That means we need to ask ISO for a solution. Q.E.D. :)
non sequitor.  :)

I agree that, in the long term, you want to get countries to publish their timezone definitions.  I also think it's useful to have them define new timezone names when needed, and to maintain the links between their names and the published definitions.  (nothing stops existing publishers from proofreading and fixing such definitions as a value-added service.)

But IMHO these names are less likely to have the right semantics if they're initially defined by ISO, than if they're initially defined by an IETF WG composed of people with experience in developing iCalendar implementations.  Remember, the challenge is to get the naming right, not the definitions themselves.  Getting the naming right means picking semantics for the names that maximizes the potential for interoperability, and picking a form for the names that encourages the right semantics.

Keith


_______________________________________________
Apps-Discuss mailing list
Apps-Discuss <at> ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss
Martin J. Dürst | 1 Apr 2009 09:34
Picon
Gravatar

Re: Minutes from informal IETF/W3C meeting about HTML5 work

At one point, it definitely was. Many people on the uri list were not
interested in IRI issues, and some i18n experts on the IRI list weren't
interested in URI issues.

Of course, times may have changed, and in case we'd decide to
stuff all the HTML5 bugwards-compatibility stuff for URIs into the
IRI spec because the URI spec is already at Full Standard, things
might change.

Regards,    Martin.

On 2009/03/31 20:10, Mark Nottingham wrote:
> Just thinking out loud -- is it *really* a good idea to have separate
> URI and IRI lists?
>
> Cheers,
Martin J. Dürst | 1 Apr 2009 10:34
Picon
Gravatar

Re: Generic URI syntax incompatible with IPv6 addresses in SIP URIs

I agree with Julian that discussion about updates of RFC 3987 (IRI spec,
new version currently at draft-duerst-iri-bis-05) should go to
public-iri <at> w3.org, whereas bug reports and discussions about RFC 3986
(URI spec) should go to uri <at> w3.org.

But Lisa, you are the AD who eventually has to handle anything that 
comes out of these drafts, so I'm glad to follow your directions.

Julian, could you be more specific (pointer is sufficient) about what 
you mean below with "potential issue (normalization)"?

Regards,    Martin.

On 2009/04/01 6:05, Julian Reschke wrote:
> Lisa Dusseault wrote:
>> Well, I'm confused. "Moving" was a loose term, but I did think I
>> heard that we should join "public-?ri" (didn't hear very clearly at
>> the bar bof) and "public-iri" was the match I found. Since I'm a
>> newcomer to either list (URI work has been pretty slow while I've been
>> AD), just let me know which list we should use to discuss updating the
>> IETF URI RFCs.
>
> Well, we've got both
>
> <http://lists.w3.org/Archives/Public/public-iri/>
>
> and
>
> <http://lists.w3.org/Archives/Public/uri/>
>
> As far as I can tell, the discussion is about:
>
> - a potential issue with the IRI spec (normalization)
>
> and
>
> - a potential addition already drafted in RFC3987bis (LEIRIs)
>
> In particular, I haven't seen any bugs reported against RFC3986 in this
> context (except the lack of error handling requirements, which clearly
> is controversial).
>
> Thus, it seems that we are really talking about RFC3987bis, and thus the
> IRI mailing list would be the right place.
>
> BR, Julian
> _______________________________________________
> Apps-Discuss mailing list
> Apps-Discuss <at> ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

--

-- 
#-# Martin J.Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst <at> it.aoyama.ac.jp
Julian Reschke | 1 Apr 2009 10:52
Picon
Picon

Re: Generic URI syntax incompatible with IPv6 addresses in SIP URIs

Martin J. Dürst wrote:
> I agree with Julian that discussion about updates of RFC 3987 (IRI spec,
> new version currently at draft-duerst-iri-bis-05) should go to
> public-iri <at> w3.org, whereas bug reports and discussions about RFC 3986
> (URI spec) should go to uri <at> w3.org.
> 
> But Lisa, you are the AD who eventually has to handle anything that 
> comes out of these drafts, so I'm glad to follow your directions.
> 
> Julian, could you be more specific (pointer is sufficient) about what 
> you mean below with "potential issue (normalization)"?
> 
> Regards,    Martin.

It's the one raised by Anne vK: Section 3.1 requires different IRI->URI 
behavior depending on the encoding of the source document:

    Step 1.  Generate a UCS character sequence from the original IRI
             format.  This step has the following three variants,
             depending on the form of the input:

             a. If the IRI is written on paper, read aloud, or otherwise
                represented as a sequence of characters independent of
                any character encoding, represent the IRI as a sequence
                of characters from the UCS normalized according to
                Normalization Form C (NFC, [UTR15]).

             b. If the IRI is in some digital representation (e.g., an
                octet stream) in some known non-Unicode character
                encoding, convert the IRI to a sequence of characters
                from the UCS normalized according to NFC.

             c. If the IRI is in a Unicode-based character encoding (for
                example, UTF-8 or UTF-16), do not normalize (see section
                5.3.2.2 for details).  Apply step 2 directly to the
                encoded Unicode character sequence.

It would be helpful to understand where exactly this requirement comes 
from, and whether we have evidence it's being implemented (or even 
implementable; the source document encoding may not be known at the 
moment where the URI->IRI conversion occurs).

BR, Julian
Stephane Bortzmeyer | 1 Apr 2009 10:48
Picon

Re: Solicitation for a discussion on Keyword-based addressing

On Wed, Apr 01, 2009 at 11:16:36AM +0800,
 zhangguoqiang <zhangguoqiang <at> cnnic.cn> wrote 
 a message of 156 lines which said:

> Different from search engines, keyword-based addressing is an
> addressing technology. Based on whether a keyword is registered or
> not, the resolution result is determinstic for any given keyword, 

Then it will have all the problems of the domain names, including
bureaucratic registration rules, UDRP, lawyers, ICANN, etc.

> For example, if you are a blogger of a portal blog website,
> typically, you are assigned a URL that identifies your blog. It is
> usually composed of two parts: a domain name and an ID(typically a
> magic number). So how can you advertise your blog to your friends? 

tinyurl.com

But it is simpler to buy a domain name and redirect.

> So, we think keyword-based addressing is a very useful technique,
> especially for non-english speaking countries. Even for english
> speaking countries, the above example also illustrates its
> practicability. To internationalize this service and provide cross
> resolution capability, we highly recommend a standard being
> developped. 

I'm very skeptical but I'll read your draft.

> Our keyword-based addressing draft is available at
> http://tools.ietf.org/html/draft-zhang-keyword-ddds-00, which
> specifies keyword-based addressing as a DDDS application.

You apparently do not mention RFC 2345 (keywords are a very old idea
which keep popping up from time to time).
zhangguoqiang | 1 Apr 2009 10:55
Picon

Re: Re: Solicitation for a discussion on Keyword-based addressing

The dispute is inevitable. But policy issues don't prevent domain names from being widely used, and it should not prevent keyword as well.  
 
 
2009-04-01
zhangguoqiang
发件人: Stephane Bortzmeyer
发送时间: 2009-04-01  16:48:32
收件人: zhangguoqiang
抄送: apps-discuss; YAO Jiankang
主题: Re: Solicitation for a discussion on Keyword-based addressing
On Wed, Apr 01, 2009 at 11:16:36AM +0800,
 zhangguoqiang  <zhangguoqiang <at> cnnic.cn > wrote 
 a message of 156 lines which said:
 
> Different from search engines, keyword-based addressing is an
> addressing technology. Based on whether a keyword is registered or
> not, the resolution result is determinstic for any given keyword, 
 
Then it will have all the problems of the domain names, including
bureaucratic registration rules, UDRP, lawyers, ICANN, etc.
 
> For example, if you are a blogger of a portal blog website,
> typically, you are assigned a URL that identifies your blog. It is
> usually composed of two parts: a domain name and an ID(typically a
> magic number). So how can you advertise your blog to your friends? 
 
tinyurl.com
 
But it is simpler to buy a domain name and redirect.
 
> So, we think keyword-based addressing is a very useful technique,
> especially for non-english speaking countries. Even for english
> speaking countries, the above example also illustrates its
> practicability. To internationalize this service and provide cross
> resolution capability, we highly recommend a standard being
> developped. 
 
I'm very skeptical but I'll read your draft.
 
> Our keyword-based addressing draft is available at
> specifies keyword-based addressing as a DDDS application.
 
You apparently do not mention RFC 2345 (keywords are a very old idea
which keep popping up from time to time).
Attachment (张国强(1).vcf): text/x-vcard, 286 bytes
_______________________________________________
Apps-Discuss mailing list
Apps-Discuss <at> ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

Gmane