Subject: [iucg] IUser information

From: jefsey <[email-masked]>
Date: Thu, 25 Aug 2011 03:15:13 +0200

Dear IUsers,
some clarification in terms of IUser documentation:

1. Unicode seems to deny IUsers the right to study and discuss the 
Unicode terminology. This seems preposterous and in conflict with WTO 
basic documetation rules.
2. After the intervention of Unicode VP, I  have published a 
description  of IUWW (IUser Working  Wiki). http://iucg.org/wiki/IUWW
3. Russ Hosley (IETF, Chair) puts an official end to the FYI 
sub-series of RFC destined, by the IETF user area to inform the public

If you have any comment you are welcome.
RFC 6360 being short enough, I provide its text for direct perusal 
and possible debate: over the IUCG's scope.

------

Internet Engineering Task Force (IETF)                        R. Housley
Request for Comments: 6360                                Vigil Security
Obsoletes: 1150                                              August 2011
Category: Informational
ISSN: 2070-1721

                     Conclusion of FYI RFC Sub-Series

Abstract

    This document concludes the For Your Information (FYI) sub-series of
    RFCs, established by RFC 1150 for use by the IETF User Services Area,
    which no longer exists.  The IESG does not intend to make any further
    additions to this RFC sub-series, and this document provides a record
    of this decision.  This document also obsoletes RFC 1150 and changes
    the status of RFC 1150 to Historic.

Status of This Memo

    This document is not an Internet Standards Track specification; it is
    published for informational purposes.

    This document is a product of the Internet Engineering Task Force
    (IETF).  It represents the consensus of the IETF community.  It has
    received public review and has been approved for publication by the
    Internet Engineering Steering Group (IESG).  Not all documents
    approved by the IESG are a candidate for any level of Internet
    Standard; see Section 2 of RFC 5741.

    Information about the current status of this document, any errata,
    and how to provide feedback on it may be obtained at
    http://www.rfc-editor.org/info/rfc6360.

Copyright Notice

    Copyright (c) 2011 IETF Trust and the persons identified as the
    document authors.  All rights reserved.

    This document is subject to BCP 78 and the IETF Trust's Legal
    Provisions Relating to IETF Documents
    (http://trustee.ietf.org/license-info) in effect on the date of
    publication of this document.  Please review these documents
    carefully, as they describe your rights and restrictions with respect
    to this document.  Code Components extracted from this document must
    include Simplified BSD License text as described in Section 4.e of
    the Trust Legal Provisions and are provided without warranty as
    described in the Simplified BSD License.

1.  Background

    The For Your Information (FYI) sub-series of RFCs was established by
    RFC 1150 [RFC1150] in 1990 for use by the IETF User Services Area,
    which has not met since IETF 53 held in March 2001.  This RFC sub-
    series was designed to provide Internet users with a repository of
    information regarding the Internet that might be interesting to a
    wide range of people.

    The publication of RFC 1150 [RFC1150] introduced the FYI sub-series
    of RFCs.  Since that time, a total of 38 FYI numbers have been
    assigned.  Many other Informational RFCs have been published that are
    not part of the FYI sub-series.

    The list of documents in the FYI sub-series can be found on the RFC
    Editor web site [INDEX].

2.  Conclusion of the FYI Sub-Series

    The IESG does not intend to make any further additions to the FYI
    sub-series.  The IESG intends to continue to produce Informational
    RFCs, but none of them will be assigned an FYI number.

    All published RFCs that are currently part of the FYI sub-series will
    retain their FYI numbers.  The FYI numbers continue to provide
    reference points for these documents, and the FYI number can be used
    in citations to these documents.

    If a future RFC is published that obsoletes an existing member of the
    FYI sub-series, the new RFC will not be assigned an FYI number.

3.  RFC 1150 Moved to Historic

    This document moves RFC 1150 [RFC1150] to Historic.  The procedural
    information in RFC 1150 is no longer valid.  If it becomes desirable
    to make additions to the FYI sub-series in the future, new procedures
    can be developed to replace this document.

4.  Security Considerations

    No Internet security issues are anticipated by the actions described
    in this document.

5.  References

5.1. Normative Reference

    [RFC1150] Malkin, G. and J. Reynolds, "FYI on FYI: Introduction to
              the FYI Notes", FYI 1, RFC 1150, March 1990.

5.2.  Informative Reference

    [INDEX]   "FYI Index", http://www.rfc-editor.org/fyi-index.html

Author's Address

    Russell Housley
    Vigil Security, LLC
    918 Spring Knoll Drive
    Herndon, VA 20170
    USA
    EMail: [email-masked]
-----

Best.
jfc

---

From: Marie-France Berny <[email-masked]>
Date: Thu, 25 Aug 2011 10:35:40 +0200

Jefsey,
It seems that the task of informing users and for IUsers to document their
own environment through the IETF system (RFCs) is a too large task. Because
we are a too little number.  Because people are just not interested. Because
the principle of an RFC pile instead of some smart updated mindmap maybe
adequate to the IETF process, but is not to IUse.

>From what I read of FYIs, it was something not updated and centered on the
way experts wanted to explain and not on users' demands.

Our own iuwwws could be a response if we had different approach from RFCs,
some kind of RFC mindmap, with only the main ideas. But there is no such a
tool (even thebrain is not adequate since one cannot arrange links in a
logic order, only alphabetical order).

What would be necessary would be:

- to build a noomap management system, a map of what we really have in the
brain, that mindmaps may further on play with. May be based on Excel.
- to associate it to a registry system like the ISO one we discuss but have
no time to look into.
- to forget about copyrights because the issue is not what is copied, but
what is inside. Fed-up with people wanting us to pay everything or tell who
told us what including what is in our brain! (but not telling us who told
them !!!!)

This being said. May be if we could find a list of the FYIs it could be
interesting?
MFB

2011/8/25 jefsey <[email-masked]>

> 1. Unicode seems to deny IUsers the right to study and discuss the Unicode
> terminology. This seems preposterous and in conflict with WTO basic
> documetation rules.
> 2. After the intervention of Unicode VP, I  have published a description
> of IUWW (IUser Working  Wiki). http://iucg.org/wiki/IUWW
> 3. Russ Hosley (IETF, Chair) puts an official end to the FYI sub-series of
> RFC destined, by the IETF user area to inform the public
>
> RFC 6360 being short enough, I provide its text for direct perusal and
> possible debate: over the IUCG's scope.
>
> ------
>
> Internet Engineering Task Force
> (IETF)
> R. Housley
> Request for Comments:
> 6360
> Vigil Security
> Obsoletes:
> 1150
> August 2011
> Category: Informational
> ISSN: 2070-1721
>
>
>
> (
> http://trustee.ietf.org/license-info) in effect on the date of
> _______________________________________________
> iucg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/iucg
>
>

---

From: JFC Morfin <[email-masked]>
Date: Thu, 25 Aug 2011 13:09:26 +0200

At 10:35 25/08/2011, Marie-France Berny wrote:
>- to forget about copyrights because the issue is not what is 
>copied, but what is inside. Fed-up with people wanting us to pay 
>everything or tell who told us what including what is in our brain! 
>(but not telling us who told them !!!!)

This is an interesting idea to legally dig into. The copyrights on a 
mindmap content. I suppose this is a matter for the cafedu.com 
mailing list. I will think about it as a part of the extended theory 
of systems. What has become an intrinsic part of an intricated system 
should not be considered separately even if one can trace its origin. 
This means that the copyrights should be on the transport of an 
independent element. Once the element is melt into a larger system 
(in toto or in part) its true origin is lost beause its true semantic 
has evoluated? So the copyrights should be on the first leg of such a 
transport.

There should be some praetorian laws on this. What about looking at 
rules on tracability?

This definitly call for me to summarise somewhere the system extended 
theory, including the points on the entelechy, form, substance, 
essence, cortege, data, metadata, syllodata. but I am not sure this 
is yet stable enough. However, we need to have a try to an MDRS even 
a rustic one (that will probably give us new ideas). You also gave me 
an idea about maps. One can say that all of them are drafts from 
(personal or collective) ontographies. But the same as there are 
different kind of geographic maps, why not some different noetic 
maps. One of them could be a "semmap" understood as a neutral open 
semantic map (i.e. what we want to experiment with Projet.FRA)

Let try this:

1. we try to address the IUI virtual system first.
2. we try to add the SDNS support in it, with ML-DNS initial 
operations as a test.
3. we try to work on SQLite and port it to the virtual system
4. we try to get someone explaining us what the JTC1/SC32/WG2 really 
does and how we could build someting conformant for the MDRS.
5. as a test we get the iuww multilingual internet glossary in it. We 
will document this as a part of the intertest project.

The interest I would see in this is that SQLite, if I am correct, can 
be exported as a single file and supports MediaWiki. This would make 
a "semmap" format. Then we could articulate some analysis/integration 
cognitive and update tools. In such a case only members of a 
relational space could share better their ontographies (that is our target?).

At the same time we try to get a graphcode systemic to support a 
variant algorithm. If we use it instead of Unicode in the core of the 
MDRS and getting texts polylingualized ... plus the entire stuff 
being encrypted we would have a good support tool for a bold polynym basis?

Now, if I am correct from what you propose :

1. someone does an original work. He/she get author rights, basically 
to be called upon to work on his idea and in so doing being possibly paid.
2. someone becomes the owner of that work and wants to get paid for 
its paid copies.
3. the original work gets amalgamated with others' works in persons 
ontgraphies/ontologies by the original work of these persons. These 
persons do not much care about the current owner, but care about the 
inventor (to be able to discuss peculiarities with him, or 
successors, for example). So they should retain the source and the 
author as metadata.
4. the "ontomagma" can then be shared with third parties, i.e. 
transported but only the person's original work is on its first 
transport leg. So the copyrights are only with that last person.
5. the same rule applies for all the additioins to the ontomagma 
(extensions, translations) etc.

Does that sound correct?
jfc

---

From: Marie-France Berny <[email-masked]>
Date: Fri, 26 Aug 2011 01:56:41 +0200

Jefsey,
I am OK with the ontomagma concept!. Let make your mail rest in digesting
peace for a few weeks and then let talk about a real plan.

The only addition I suggest, from Unicode's declaration of war to their
Internet users, is that we remove every reference to Unicode further on. Not
in retaliation, But because they demonstrated they really are not network
minded and user oriented.
MFB

2011/8/25 JFC Morfin <[email-masked]>

> mindmap content. I suppose this is a matter for the cafedu.com mailing
> list. I will think about it as a part of the extended theory of systems.
> What has become an intrinsic part of an intricated system should not be
> considered separately even if one can trace its origin. This means that the
> copyrights should be on the transport of an independent element. Once the
> element is melt into a larger system (in toto or in part) its true origin is
> lost beause its true semantic has evoluated? So the copyrights should be on
> the first leg of such a transport.
>
> There should be some praetorian laws on this. What about looking at rules
> on tracability?
>
> theory, including the points on the entelechy, form, substance, essence,
> cortege, data, metadata, syllodata. but I am not sure this is yet stable
> enough. However, we need to have a try to an MDRS even a rustic one (that
> will probably give us new ideas). You also gave me an idea about maps. One
> can say that all of them are drafts from (personal or collective)
> ontographies. But the same as there are different kind of geographic maps,
> why not some different noetic maps. One of them could be a "semmap"
> understood as a neutral open semantic map (i.e. what we want to experiment
> with Projet.FRA)
>
> Let try this:
>
> 2. we try to add the SDNS support in it, with ML-DNS initial operations as
> a test.
> 4. we try to get someone explaining us what the JTC1/SC32/WG2 really does
> and how we could build someting conformant for the MDRS.
> 5. as a test we get the iuww multilingual internet glossary in it. We will
> document this as a part of the intertest project.
>
> The interest I would see in this is that SQLite, if I am correct, can be
> exported as a single file and supports MediaWiki. This would make a "semmap"
> format. Then we could articulate some analysis/integration cognitive and
> update tools. In such a case only members of a relational space could share
> better their ontographies (that is our target?).
>
> At the same time we try to get a graphcode systemic to support a variant
> algorithm. If we use it instead of Unicode in the core of the MDRS and
> getting texts polylingualized ... plus the entire stuff being encrypted we
> would have a good support tool for a bold polynym basis?
>
> 1. someone does an original work. He/she get author rights, basically to be
> called upon to work on his idea and in so doing being possibly paid.
> 2. someone becomes the owner of that work and wants to get paid for its
> paid copies.
> ontgraphies/ontologies by the original work of these persons. These persons
> do not much care about the current owner, but care about the inventor (to be
> able to discuss peculiarities with him, or successors, for example). So they
> should retain the source and the author as metadata.
> 4. the "ontomagma" can then be shared with third parties, i.e. transported
> but only the person's original work is on its first transport leg. So the
> copyrights are only with that last person.
> ______________________________**_________________
> iucg mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/iucg<https://www.ietf.org/mailman/listinfo/iucg>
>

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Fri, 26 Aug 2011 06:53:13 +0300

> sub-series of RFC destined, by the IETF user area to inform the public

1. This was a decision of the whole IESG; note the draft's name being 
draft-*iesg*-rfc1150bis.
2. Conclusion of FYI seb-series had a formal reason only - absence of 
user services area, which ceased to exist.  Considered that, and the 
issue that RFC 1150 was clear regarding review of proposed FYIs by user 
services area wg, I believe that such decision is fair.
3. If you didn't want IESG to do so, you should have spoken up during 
Last Call.
4. If you didn't like IESG decision, you should have appealed as 
discussed in RFC 2026.

> If you have any comment you are welcome.

Why provide comments on already published RFC?  See bullet 3 above.

M. Yevstifeyev

---

From: JFC Morfin <[email-masked]>
Date: Fri, 26 Aug 2011 09:40:22 +0200

Dear Mykyta,
"Why provide comments on already published RFC?" Because RFC means 
request for comments.

I am afraid I was not clear enough. We have acquired experience. 
There was a user services area. Russ has accepted the IUCG list which 
is a new way to make users present and represented in the IETF. Our 
job is to find an adequate way to support the Internet (Engineering 
Task Force) User and their contribution. The way we explore has been 
opposed by Unicode, resulting in our distrust in the Unicode 
technical transparency and therefore adequacy for the Internet (until 
the growing influence of Google, the IETF trusted ISO 10646). As a 
result we have better defined the working method we think adequate.

Not only I do not oppose the IESG but I support its move. Up to us to 
imagine what to better do now if there is a better way than FYIs. 
Also, you certainly know that Unicode has made sure I cannot speak up 
on the IETF list.
Best
jfc

At 05:53 26/08/2011, Mykyta Yevstifeyev wrote:
>1. This was a decision of the whole IESG; note the draft's name 
>being draft-iesg-rfc1150bis.
>2. Conclusion of FYI seb-series had a formal reason only - absence 
>of user services area, which ceased to exist.  Considered that, and 
>the issue that RFC 1150 was clear regarding review of proposed FYIs 
>by user services area wg, I believe that such decision is fair.
>3. If you didn't want IESG to do so, you should have spoken up 
>during Last Call.