Subject: Re: [iucg] [happiana] Focusing on happy

From: JFC Morfin <[email-masked]>
Date: Mon, 07 Nov 2011 00:13:59 +0100

At 01:33 05/11/2011, Michelle Cotton wrote:
>Ned,
>
>I think some of the conversation got derailed (at least I thought it did -
>not sure others agree).  I was just trying to get back to specific things to
>be fixed, label them simple/more complex....I need to go back to my
>developer with a list of things to change/fix.  Figure out what changes can
>be made without any RFC revisions/etc.

Michelle,

There actually are two classes of people to make happy:

- the IETF information registrants - on this IETF list they should 
have the priority.
- the IANA users who may include non-IETF registrants since the IANA 
charter is not limited to  IETF registries.

I am not competent to discuss the first class.
I am definitly pionneering the second one with the IUCG as the 
"Internet, IETF, IANA users contributing group": people targeted by 
RFC 6417. To fully understand what our/their needs are, along with 
the Internet common way, we have to discuss, experiment and propose.

To that end I started keeping updated a IANA  WinHTTrack copy  with 
the files linked  on external sites.

This currently represents :

- 23,143 files (of which 4962 have an IANA URL).
- 3,793,589,988 bytes (of which 28,370,696 comes from the IANA server).

(I can send you a copy of my findings as a table or a csv file, for 
comparison).

Attracting researchers and lead users to the IETF (RFC 6147) calls 
for matching their culture. They will want accessible, reliable 
registries they and their applications can directly interact with and 
use for additional registries (statistics, tests, etc.). They will 
therefore demand a stable and enforced documentation on the IANA file 
directories, logic, content, file format, etc..

The main contention I had during the RFC 4646 saga was the size of 
the langtag tables and the lack of end-user update system; except a 
complete download of the table. This would quickly double the whole 
internet traffic in just accessing the IANA if every user requested a 
daily update (full table download) to be sure his/her smartphone is 
linguistically up to date.

This is why I think the best solution would be :

- to conceive an independent intermediate documented stable IANA structure
- to publish a formated daily reports, applications might use to 
request urgent updates
- for everyone to be able to maintain his/her own tables
- the inner IANA system freely evoluate only having a fixed 
information structure.

At this stage I am interested in (on an experimental basis):

- understanding which directories (IANA directories and external 
sites) the IANA really represents.
- experimenting their stability and interfacing their format.
- building a single base that can be zipped (probably as an SQLite 
file) on AKAMAI, with a reader and an updater for futher local copies 
distribution.
- exploring the best/cheapest way to keep its information updated at 
million sites.
- adding global, specialized and private use registries.
- documenting the whole set.

I whish to know:

- if this is acceptable to your strategy.
- your comments.
- how your team could help.

jfc

>On 11/4/11 1:53 PM, "Ned Freed" <[email-masked]> wrote:
>
> >> Will this group be meeting in Taipei?
> >
> > What would be the point? We've made essentially no progress in 
> either previous
> > meetings or via email. Lists of specific changes to consider have 
> been posted
> > by both Mark and myself; discussion of both lists died out almost 
> immediately.
> > <[email-masked]> is my suggestion list plus some
> > additions; <[email-masked]> is my response to Mark's
> > list.
> >
> > We also have an active draft revising media type registrations 
> that urgently
> > needs review; reviews which were promised by September and aside from one
> > editorial review, have not materialized.
> >
>I have read the document and will send you my comments/questions for the
>document.
>
> >> Perhaps to discuss what bits of improvements/clarifications from 
> this group
> >> can go in 5226bis and also to discuss other action items?
> >
> > And here I was thinking the goal was to figure out how to 
> streamline existing
> > registration processes. It's news to me that a revision of 5226 
> was ever the
> > goal here. It wasn't mentioned as a goal in the announcement of 
> the purpose of
> > this list.
> >
>
>This was not the goal of this group.  Improvements in general both on the
>submission of requests/transparency of status/etc were the goals...I think.
>
>However, it seemed based on some of the email conversations some of what is
>being suggested would fit into the revision of 5226 rather than having a
>separate document.
>
>Goal: Make some improvements, hopefully making people happy
>
>I'm still up for meeting in Taiwan to make a concrete list of actions.
>
>--Michelle
>
> > Ned
>
>_______________________________________________
>happiana mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/happiana

---

From: jean-michel bernier de portzamparc <[email-masked]>
Date: Mon, 7 Nov 2011 01:39:04 +0100

Jefsey,

I looked at the initial table you produced.

the work ahead seems to be consequent. Moreover if there is no warranty of
a stable format from the IANA.
Did you consider your "intermediary formated structure" as an test MDRS
structure?

Anyway what we would all need is an "insider" technical description of the
IANA architecture, and a searchable file content database. This would also
document the IANA team's experience. Does such a document exist? From your
table, most of the IANA files are HTML only one PDF, so I guess not. There
is nothing looking as a IANA developper manual or even a printed/maintaiend
user information.

Or should we try to document each of the 4962 "iana files" in the table? In
such a case we should probably:
- produce a .csv format
- develop a program to extract this table and consider its evolution
easily. I can have a look at an rdlab development.

Best would be a cooperation with the IANA team.
Portzamparc.

2011/11/7 JFC Morfin <[email-masked]>

> - the IETF information registrants - on this IETF list they should have
> the priority.
> I am definitly pionneering the second one with the IUCG as the "Internet,
> IETF, IANA users contributing group": people targeted by RFC 6417. To fully
> understand what our/their needs are, along with the Internet common way, we
> have to discuss, experiment and propose.
>
> To that end I started keeping updated a IANA  WinHTTrack copy  with the
> files linked  on external sites.
>
> Attracting researchers and lead users to the IETF (RFC 6147) calls for
> matching their culture. They will want accessible, reliable registries they
> and their applications can directly interact with and use for additional
> registries (statistics, tests, etc.). They will therefore demand a stable
> and enforced documentation on the IANA file directories, logic, content,
> file format, etc..
>
> The main contention I had during the RFC 4646 saga was the size of the
> langtag tables and the lack of end-user update system; except a complete
> download of the table. This would quickly double the whole internet traffic
> in just accessing the IANA if every user requested a daily update (full
> table download) to be sure his/her smartphone is linguistically up to date.
>
> - to publish a formated daily reports, applications might use to request
> urgent updates
> - the inner IANA system freely evoluate only having a fixed information
> structure.
>
> - understanding which directories (IANA directories and external sites)
> the IANA really represents.
> - building a single base that can be zipped (probably as an SQLite file)
> on AKAMAI, with a reader and an updater for futher local copies
> distribution.
>> > What would be the point? We've made essentially no progress in either
>> previous
>> > meetings or via email. Lists of specific changes to consider have been
>> posted
>> > <01O4OSHQRWC400VHKR@mauve.**mrochek.com<[email-masked]>>
>> is my suggestion list plus some
>> > additions; <01O559KSSS5800VHKR@mauve.**mrochek.com<[email-masked]>>
>> is my response to Mark's
>> > list.
>> >
>> > We also have an active draft revising media type registrations that
>> urgently
>> >> Perhaps to discuss what bits of improvements/clarifications from this
>> group
>> > And here I was thinking the goal was to figure out how to streamline
>> existing
>> > registration processes. It's news to me that a revision of 5226 was
>> ever the
>> > goal here. It wasn't mentioned as a goal in the announcement of the
>> purpose of
>> > this list.
>> >
>>
>> ______________________________**_________________
>> happiana mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/happiana<https://www.ietf.org/mailman/listinfo/happiana>
>>
>
> ______________________________**_________________
> iucg mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/iucg<https://www.ietf.org/mailman/listinfo/iucg>
>

---

From: JFC Morfin <[email-masked]>
Date: Mon, 07 Nov 2011 15:08:31 +0100

Jean-Michel,

This is the crux for us, and for the Internet.

At 01:39 07/11/2011, jean-michel bernier de portzamparc wrote:
>the work ahead seems to be consequent. Moreover if there is no 
>warranty of a stable format from the IANA.
>Did you consider your "intermediary formated structure" as an test 
>MDRS structure?
>
>Anyway what we would all need is an "insider" technical description 
>of the IANA architecture, and a searchable file content database. 
>This would also document the IANA team's experience. Does such a 
>document exist? From your table, most of the IANA files are HTML 
>only one PDF, so I guess not. There is nothing looking as a IANA 
>developper manual or even a printed/maintaiend user information.
>
>Or should we try to document each of the 4962 "iana files" in the 
>table? In such a case we should probably:
>- produce a .csv format

The general issue, as I perceive it from the different inputs on the 
happiana mailing list, results from Peter Saint-Andre's impossible 
targeted task. I'll quote him here:

>We're not here with a clean slate to rewrite RFC 5226 or core
>IANA procedures. Instead, we're here to improve the interface to the
>IANA for both IETF participants and other SDOs (the primary SDO that
>gave rise to this discussion was the W3C because the Applications ADs
>tend to help process standards tree registrations for web technologies,
>but there might be other SDOs in the mix).

This is to say: I want a very nice, wide car, doing what I want on 
the road, security for my family, impress my neighborhood, be able to 
transport all of my friends, etc. but all I have is a bunch of bikes 
and I do not have the money for any other vehicle. I want to focus on 
being happy, and not on the work that is to make it happen.

So, as a result:

>As I wrote yesterday to the
>[email-masked] list, as part of our work here we might collaborate on
>"bis" documents regarding registration procedures for URI schemes (RFC
>4395), link relations (RFC 5988), media types (RFC 4288), header fields
>(RFC 3864) primarily for HTTP, and perhaps others. I'll let IANA folks
>talk share their thoughts, but one idea that's been floated is to
>improve visibility into the IANA ticketing system so that registrants
>from, say, the W3C could see their request as it moves through the
>process without needing to pester the relevant Area Director.

This means that one can only (too complicated otherwise) plaster 
patches on the bikes and tell people how to use them as if they were 
a big, nice car.

>I'm out of time for now but just wanted to make sure that we have a
>broadly similar set of expecations about what we're trying to accomplish
>here.

What we need is a clear description of the IANA engine for all the 
seasons, the way it works and the way that it is to be used, and the 
IANA specifications that are to be approved by the IESG as the exact 
program for that IANA engine to run along the RFC, i.e. its user manual.

This really means a clean slate approach. Either this is engaged by 
the IETF for the Internet, written by the IANA team and documented 
for its clients (including the IETF), or it is designed elsewhere. 
This problem is a recurrent problem that I have faced for 35 years: 
to jointly document the network to peers, so that they can themselves 
document it to their users. From this I identified the need for a 
distributed system permitting everyone to document everything to the 
attention of everyone who needs it and of his/her machines. I called 
that system MDRS, which stands for Meta-Data Registry/Multilingual 
Distributed Referential System. This turned out to be the Intersem 
Internet-IANA architectural equivalent (and probable extension/continuation).

Until now, I have only tried to avoid complicating the resolution of 
this complex issue, in particular in the multiglobal area 
(multilingual, multitechnology, international, national strategies, 
cultures, transdisciplinary exploration, etc.). I hoped Peter's 
effort can be a basis for a step ahead. I am afraid, from reading the 
happianna mailing list that the only solution is for the IUsers 
(Interdigital ecosystem users) emerging community to do this for 
themselves, based on the existing IANA, ISO, Linguasphere, etc. 
material, our passed Intlnet and JTC1, IETF DDDS/DNS deployment 
experience, and Intersem under the exploration requirements.

Now, the issue we also have to match, towards good and robust MDRS 
specifications, is simplifying complexity. This means understanding 
in a practical manner what complexity and simplicity are and how to 
computer assist them in the best way, which means to equally master 
meta-complexity and meta-simplicity. This may seem somewhat esoteric 
at this stage, but it is necessary when considering the seed of the 
system to actually structure the semantic layer of communications.

Understand that for the sole Internet (passive content strata) there 
are 96 different IANA related RFCs, if you add ISO 3166 and 639 etc., 
ISO 11179 series, Linguasphere open source elements, it becomes which 
is, actually, way too much.

>Best would be a cooperation with the IANA team.

Up to them to decide.

jfc