Subject: [Ltru] Re: Language-tag base URI (was: Language Tag MIB Textual Convention)

From: "Doug Ewell" <[email-masked]>
Date: Fri, 10 Nov 2006 23:52:31 -0800

John Cowan <cowan at ccil dot org> wrote:

>> But language tags are not URIs,
>
> Hmm.  Syntactically, they look like relative references.  Perhaps 
> 4646bis should define a base URI so that people who want to use URIs 
> in place of language tags have an easy way to do so?
>
> http://www.iana.org/assignments/language-tags/ is available.

One well-known problem with http-style URIs like this is that people 
expect them to resolve to a resource, and become convinced that 
something is wrong or broken when they don't.  That is what would happen 
in this case, unless someone volunteers to create an addressable 
resource for every possible generative language tag.

Another possibility is RFC 4151 "tag" URIs, which are intended to be 
identifiers only, and not supposed to resolve to any resource.  A few 
examples, made up purely for illustration, might be:

tag:iana.org,1995-07:lsr:en
tag:iana.org,1995-07:lsr:zh-Hans

I should point out that this has nothing to do with the proposal made 
repeatedly last year by JFC Morfin to reserve a singleton ("0-") to 
introduce an RFC 4151 tag URI to a language tag, which would have made 
every such language tag "unique across space and time" (as stated in RFC 
4151) and would have defeated the purpose of tag matching (as well as 
breaking the syntax of RFC 4646).  Using tag URIs for the MIB 
application is exactly the opposite: it would map language tags onto the 
tag URI structure, not the other way around.

I guess I'll get some "semi-private," bcc-addressed spam in my bit 
bucket tomorrow.

--
Doug Ewell  *  Fullerton, California, USA  *  RFC 4645  *  UTN #14
http://users.adelphia.net/~dewell/
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages

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

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 11 Nov 2006 13:50:28 +0100

Doug Ewell wrote:

> people expect them to resolve to a resource, and become convinced
> that something is wrong or broken when they don't

Of course, if you'd want only an identifier why start it with http: ?
If you'd insist on http: let the URLs at least redirect to a better
page than some err404.html.

It would be also bad if .../Latn and .../Lala both result in a 404.

> tag:iana.org,1995-07:lsr:zh-Hans

That's very near to this idea:
http://article.gmane.org/gmane.ietf.languages/2983

Frank

---

From: John Cowan <[email-masked]>
Date: Sat, 11 Nov 2006 12:54:51 -0500

> Of course, if you'd want only an identifier why start it with http: ?

I'm not particularly in love with http:.  My point (which is not
satisfied by a set of tag: or urn:ietf: URIs) is to provide a single
*base* URI against which language tags can be resolved as relative
references according to the rules of STD 66.

> page than some err404.html.

It would be very easy to write a dynamic application that served that
purpose.

-- 
And through this revolting graveyard of the universe the muffled, maddening
beating of drums, and thin, monotonous whine of blasphemous flutes from
inconceivable, unlighted chambers beyond Time; the detestable pounding
and piping whereunto dance slowly, awkwardly, and absurdly the gigantic
tenebrous ultimate gods -- the blind, voiceless, mindless gargoyles whose soul
is Nyarlathotep. (Lovecraft) John [email-masked]|ccil.org/~cowan

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 11 Nov 2006 19:52:41 +0100

John Cowan wrote:

> *base* URI

ACK, I forgot that, my reply was more about Doug's tag: proposal.
In theory PURLs could do that if IANA doesn't like thousands of
redirections on their server.  

Frank

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 11 Nov 2006 12:30:34 -0800

Hi -

As a technical contributor...

This thread's recent messages make no sense whatsoever to me.
The only reason that language tags and URIs were mentioned
together initially in this thread is that in the SNMP community, a need for
for a few new datatypes has been recognized.  One of them would
be for language tags, and another for URIs.  All they have in
common is:

   - they're both TEXTUAL CONVENTIONS (the only way to do this
     kind of thing in SNMP SMI)

   - the underlying syntax is OCTET STRING (really the only
     choice for things like this in SNMP SMI - the other base types
     are far too constraining)

   - they *might* be defined in the same MIB module (though
     there is absolutely no technical requirement to do so, and
     absolutely no technical reason to not do so)

There is no need whatsoever in the SNMP community to somehow
associate or connect the two.  The questions of datatypes for the two
things simply happened to come up at about the same time.

Randy

> From: "Frank Ellermann" <[email-masked]>
> To: <[email-masked]>
> Sent: Saturday, November 11, 2006 10:52 AM
> Subject: [Ltru] Re: Language-tag base URI
>
> John Cowan wrote:
> 
> > *base* URI
>

---

From: John Cowan <[email-masked]>
Date: Sat, 11 Nov 2006 15:50:40 -0500

> This thread's recent messages make no sense whatsoever to me.

Probably my fault.  I was not trying to contribute to the MIB
thread (as noted by the change in subject line).  I was simply
urging us to consider promulgating a base URI for language
tags, so that language tags could be reinterpreted as relative
references (per STD 66) in environments where URIs are a requirement.

This then led to the notion of a set of dereferenceable Web
resources which would produce a representation of any valid language
tag based on the current LSR.

I suppose this would require a change in charter.

-- 
Mark Twain on Cecil Rhodes:                    John Cowan
I admire him, I freely admit it,               http://www.ccil.org/~cowan
and when his time comes I shall                [email-masked]
buy a piece of the rope for a keepsake.

---

From: Martin Duerst <[email-masked]>
Date: Sat, 11 Nov 2006 20:47:19 +0900

>One well-known problem with http-style URIs like this is that people

Some people do, yes. Some people don't, depending on where they are
used.

>expect them to resolve to a resource, and become convinced that something is wrong or broken when they don't.  That is what would happen in this case, unless someone volunteers to create an addressable resource for every possible generative language tag.

It wouldn't take a lot of volunteers. It can be done with a simple script
at a higher level in the hierarchy, which takes the rest of the URI path
as an argument (PathInfo).

>Another possibility is RFC 4151 "tag" URIs, which are intended to be identifiers only, and not supposed to resolve to any resource.  A few examples, made up purely for illustration, might be:
>

For this kind of thing, the IETF also has some kind of URN namespace.
[I'm sure Frank will come up with the relevant RFC numbers in seconds.]
Not that I'm particularly fond of URNs, quite to the contrary. But just
so that it has been mentioned.

>Using tag URIs for the MIB application is exactly the opposite: it would
> map language tags onto the tag URI structure, not the other way around.

There may be other people who want to use language tags as URIs, but
the MIB people don't. The subject of a language tag MIB just came up
together with an URI MIB because both language tags and URIs are
basic datatypes for Internet applications.

Regards,    Martin.

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 11 Nov 2006 20:11:40 -0800

Hi -

> From: "John Cowan" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Saturday, November 11, 2006 12:50 PM
> Subject: Re: [Ltru] Re: Language-tag base URI
>
> Randy Presuhn scripsit:
> 

Ah, much clearer.  Thank you for the clarification.

> I suppose this would require a change in charter.

We could request such an addition.  Before doing so,
however, I think we should, in this order:
   1) complete our current work items
   2) determine whether the need for these real or merely
       theoretical
   3) determine whether the WG is interested in doing that work

Randy

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 12 Nov 2006 16:53:21 +0100

> [I'm sure Frank will come up with the relevant RFC numbers in seconds.]

All credits for finding RFC 2648 to John, please:
<http://article.gmane.org/gmane.ietf.languages/2945>

Otherwise it's in RFC 3553, urn:ietf:params:<some:thing>

> Not that I'm particularly fond of URNs, quite to the contrary.

Misha said something in the same direction.  But I'm not sure that this
stuff really "works", my attempt to register a URN for the RFC 2070 DTD
under the RFC 3688 rules got a ticket IANA #17903, but otherwise it had
no effect so far.  Otherwise we'd see something in the direction of... 

urn:ietf:params:xml:pi:-:IETF:DTD+HTML+i18N:EN

...in <http://www.iana.org/assignments/xml-registry/publicid.html>.

That's an issue for Harald's 2434bis, a registry SHOULD NOT start empty,
unless its format is 100% clear (as for the 4646 extension registry).

And it SHOULD try to list anything published before the new registry
was created.  How should the authors of 1738 or 2070 know that somebody
created obscure NAPTR or publicid registries more than a decade later ?

Frank