From jfc@morfin.org Mon Feb 6 18:20:59 2012 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EBEF21F86F9 for ; Mon, 6 Feb 2012 18:20:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.695 X-Spam-Level: X-Spam-Status: No, score=-0.695 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3aVRgrz0HBL for ; Mon, 6 Feb 2012 18:20:59 -0800 (PST) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id 1F33021F86F2 for ; Mon, 6 Feb 2012 18:20:58 -0800 (PST) Received: from 94.206-227-89.dsl.completel.net ([89.227.206.94]:50480 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1Ruafq-0000ao-Aw; Mon, 06 Feb 2012 18:20:50 -0800 Message-Id: <7.0.1.0.2.20120207015026.0cb2e508@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 07 Feb 2012 02:02:22 +0100 To: John C Klensin ,Gervase Markham , idna-update@alvestrand.no From: "J-F C. Morfin" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - morfin.org X-Source: X-Source-Args: X-Source-Dir: Cc: iucg@ietf.org, iutf@iutf.org Subject: Re: [iucg] Proposed new Firefox IDN display algorithm X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 02:20:59 -0000 At 21:24 06/02/2012, John C Klensin wrote: >Gerv, John, as long as we are talking of a Mozilla-IPI (International Plug-In) that can be used with a transparent Firefox and every other browser when in transparent mode, so we get the same result whatever the browser or we can use whatever other IPI approved by the local ISOC Chapter, ICANN, the national university association, ZDNet, the national ccTLD, etc. with Firefox there is no problem with IUsers. This is why I suggest that your mail is published as an extension of RFC 5895. Best jfc From klensin@jck.com Mon Feb 6 22:35:13 2012 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 076C721F87B8 for ; Mon, 6 Feb 2012 22:35:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 tagged_above=-999 required=5 tests=[AWL=-0.382, BAYES_00=-2.599, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvkjjwdQyp7X for ; Mon, 6 Feb 2012 22:35:12 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 1B77721F87B9 for ; Mon, 6 Feb 2012 22:35:12 -0800 (PST) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1RueaF-000LKH-Dl; Tue, 07 Feb 2012 01:31:19 -0500 Date: Tue, 07 Feb 2012 01:35:00 -0500 From: John C Klensin To: "J-F C. Morfin" , Gervase Markham , idna-update@alvestrand.no Message-ID: <56D46FA55B3A284F63A6FC0A@PST.JCK.COM> In-Reply-To: <7.0.1.0.2.20120207015026.0cb2e508@jefsey.com> References: <7.0.1.0.2.20120207015026.0cb2e508@jefsey.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: iucg@ietf.org, iutf@iutf.org Subject: Re: [iucg] Proposed new Firefox IDN display algorithm X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 06:35:13 -0000 --On Tuesday, February 07, 2012 02:02 +0100 "J-F C. Morfin" wrote: > At 21:24 06/02/2012, John C Klensin wrote: >> Gerv, > > John, > > as long as we are talking of a Mozilla-IPI (International > Plug-In) that can be used with a transparent Firefox and every > other browser when in transparent mode, so we get the same > result whatever the browser or we can use whatever other IPI > approved by the local ISOC Chapter, ICANN, the national > university association, ZDNet, the national ccTLD, etc. with > Firefox there is no problem with IUsers. I actually wasn't talking about that. My reason is one of those in which we may converge in the extreme case even if we disagree on most of the details (I'm not sure we do). I'm quite certain that there is no perfect solution to the problems and alternatives to drive Gerv's policy (and other policies in other browsers). I think that the classic remedy of "a good compromise is one that makes everyone equally unhappy" is not a good solution in this type of human interface situation. And, while I really like the idea of Gerv and his colleagues that every version of Firefox, on every platform and in every language adaptation, should behave the same way wrt IDNs, I'm not sure that is the most important objective. In particular, I think it is possible that ability to localize and to adjust to different user usage pattern may be more important. I'm also really, really afraid of the possible consequences of widespread appearance appearance of "????" or other "tried to display that and couldn't" situations. I think that many of the people who are concerned about confusion among characters are paying too little attention to that one. As a result, my preference is that: (1) Different browsers try the ideas that they think will work best so that we can all compare, ideas that are clearly good can gradually spread, and, if it turns out that there are only tradeoffs, users can make choices based on what suits their needs and matches their taste. Coming up with a universal solution (or even a clear definition of a "transparent mode") at this point seems to me to require knowledge that none of us really have, independent of whether our guesses and hypotheses agree or disagree. (2) I deliberately didn't mention it in my long note but, from a UI design standpoint, I'd like to see Firefox do two additional things. One is to provide a switch that permits a user to say "I think I'm smarter than you are and am willing to take responsibility for that belief and its consequences". If set in this case (it should obviously be off by default), it should simply disable all of the "display algorithm" stuff, causing the browser to display whatever it can in native character form. From my point of view, similar switches in other browsers to disable _their_ algorithms and approaches to the problem would be a good idea too. For reasons that I think I understand, I don't expect Mozilla to provide that switch (or perhaps to provide it and make it hard for any but the most sophisticated users to find), but I still think it would be a good idea. The second, and even more important, is that I believe the browser should provide a very accessible, very easy-to-use, transcoder for these labels. The best UI may differ among browsers and platforms, but, as an example for desktop machines, I'd like to be able to right-click on a domain name or label or even highlighted/ selected string and have all three of U-label form, A-label form, and a list of Unicode code points (in U+NNNN or \u'NNNN' form) easily available. For the user who does know what is going on (or who can learn) that particular tool/facility is likely to be far more useful in the long run than any collection of "we know more about this than you do and are here to protect you" tools. For what I think Gerv believes is the more typical user (and he is probably right) such a tool is, at worst, another feature like "display source" that will never be used. If I have to copy a string and carry it to another tool, the value of the approach goes down significantly, not just because the inconvenience might discourage me from checking strings I ought to check, but because the uncertainties of copy-and-paste operations might yield false results. As a trivial, ASCII-only, example, if I see "rn" on a small screen and in poor light, it would be a huge advantage to be able to be able to get the browser to show me code points that would tell me if I'm looking at U+006D or at U+0072 U+006E. Similar examples for far more complex IDN cases should be obvious. For that set of examples, the code point list is likely to be a lot more useful than an A-label. There will likely be other cases where the A-label (or the U-label if the A-label is displayed) will be more useful. FWIW, such a facility will, IMO, become even more important if we start seeing wide deployment of non-trivial IRIs (and, for them, %-encoded UTF-8 needs to be on the list of forms that can be seen or obtained too). > This is why I suggest that your mail is published as an > extension of RFC 5895. I actually don't think it has much to do with 5895. Independent of that, if others think it is useful enough, I could certainly put it together either as an I-D that might lead to an RFC or as an article for publication elsewhere. At least at this hour of the night, I'd guess the latter might be more appropriate, if only because the IETF and the RFC Series rarely go that far down the path toward UI design. best, john From vint@google.com Tue Feb 7 01:25:44 2012 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9CE21F8716 for ; Tue, 7 Feb 2012 01:25:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.05 X-Spam-Level: X-Spam-Status: No, score=-103.05 tagged_above=-999 required=5 tests=[AWL=-0.674, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6p8XflXhEfB for ; Tue, 7 Feb 2012 01:25:43 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id E59FB21F871C for ; Tue, 7 Feb 2012 01:25:42 -0800 (PST) Received: by iagf6 with SMTP id f6so11802758iag.31 for ; Tue, 07 Feb 2012 01:25:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:x-system-of-record:content-type; bh=h+rtIyH6FMCeO548PdHrObZxbFl9yEd/Pks+ohdsQvs=; b=pcfKk4JItsomF6M8M/EvDSLigxnKUOI9yE3IqkHvODmc2YJxEtgx7VdQj8203kaQT6 62I6b/f9rg+mKXKnRLnfRXKx6OAs3WDh9CQ8RPQ4vetwD8mf357xzQY4CRzArL2QUrYV AQ4i/4h3mm4aePcNTjiTt3pbRexSGne0VnhGk= Received: by 10.42.156.137 with SMTP id z9mr20429611icw.28.1328606740750; Tue, 07 Feb 2012 01:25:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.156.137 with SMTP id z9mr20429592icw.28.1328606740590; Tue, 07 Feb 2012 01:25:40 -0800 (PST) Received: by 10.231.67.78 with HTTP; Tue, 7 Feb 2012 01:25:40 -0800 (PST) In-Reply-To: <56D46FA55B3A284F63A6FC0A@PST.JCK.COM> References: <7.0.1.0.2.20120207015026.0cb2e508@jefsey.com> <56D46FA55B3A284F63A6FC0A@PST.JCK.COM> Date: Tue, 7 Feb 2012 04:25:40 -0500 Message-ID: From: Vint Cerf To: John C Klensin X-System-Of-Record: true Content-Type: multipart/alternative; boundary=90e6ba6135b8d1b11804b85c5c92 Cc: idna-update@alvestrand.no, Gervase Markham , iucg@ietf.org, "J-F C. Morfin" , iutf@iutf.org Subject: Re: [iucg] Proposed new Firefox IDN display algorithm X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 09:25:44 -0000 --90e6ba6135b8d1b11804b85c5c92 Content-Type: text/plain; charset=ISO-8859-1 At the risk of jumping in at mid-stream, it occurs to me that John's idea below (show U-label, show A-label, show Unicode character identifiers) is a variant of the "show source" that some users will choose to do for web pages, or "show original" for display of all the extra stuff that goes along with an email. Highlighting an FQDN and having a drop down opportunity to display it in various ways might be one way to help users signal this desire. Obviously, the u-label display won't work if the fonts aren't available. vint On Tue, Feb 7, 2012 at 1:35 AM, John C Klensin wrote: > > > --On Tuesday, February 07, 2012 02:02 +0100 "J-F C. Morfin" > wrote: > > > At 21:24 06/02/2012, John C Klensin wrote: > >> Gerv, > > > > John, > > > > as long as we are talking of a Mozilla-IPI (International > > Plug-In) that can be used with a transparent Firefox and every > > other browser when in transparent mode, so we get the same > > result whatever the browser or we can use whatever other IPI > > approved by the local ISOC Chapter, ICANN, the national > > university association, ZDNet, the national ccTLD, etc. with > > Firefox there is no problem with IUsers. > > I actually wasn't talking about that. My reason is one of those > in which we may converge in the extreme case even if we disagree > on most of the details (I'm not sure we do). > > I'm quite certain that there is no perfect solution to the > problems and alternatives to drive Gerv's policy (and other > policies in other browsers). I think that the classic remedy > of "a good compromise is one that makes everyone equally > unhappy" is not a good solution in this type of human interface > situation. And, while I really like the idea of Gerv and his > colleagues that every version of Firefox, on every platform and > in every language adaptation, should behave the same way wrt > IDNs, I'm not sure that is the most important objective. In > particular, I think it is possible that ability to localize and > to adjust to different user usage pattern may be more important. > > I'm also really, really afraid of the possible consequences of > widespread appearance appearance of "????" or other "tried to > display that and couldn't" situations. I think that many of the > people who are concerned about confusion among characters are > paying too little attention to that one. > > As a result, my preference is that: > > (1) Different browsers try the ideas that they think will work > best so that we can all compare, ideas that are clearly good can > gradually spread, and, if it turns out that there are only > tradeoffs, users can make choices based on what suits their > needs and matches their taste. Coming up with a universal > solution (or even a clear definition of a "transparent mode") at > this point seems to me to require knowledge that none of us > really have, independent of whether our guesses and hypotheses > agree or disagree. > > (2) I deliberately didn't mention it in my long note but, from a > UI design standpoint, I'd like to see Firefox do two additional > things. > > One is to provide a switch that permits a user to say "I think > I'm smarter than you are and am willing to take responsibility > for that belief and its consequences". If set in this case (it > should obviously be off by default), it should simply disable > all of the "display algorithm" stuff, causing the browser to > display whatever it can in native character form. From my point > of view, similar switches in other browsers to disable _their_ > algorithms and approaches to the problem would be a good idea > too. For reasons that I think I understand, I don't expect > Mozilla to provide that switch (or perhaps to provide it and > make it hard for any but the most sophisticated users to find), > but I still think it would be a good idea. > > The second, and even more important, is that I believe the > browser should provide a very accessible, very easy-to-use, > transcoder for these labels. The best UI may differ among > browsers and platforms, but, as an example for desktop machines, > I'd like to be able to right-click on a domain name or label or > even highlighted/ selected string and have all three of U-label > form, A-label form, and a list of Unicode code points (in U+NNNN > or \u'NNNN' form) easily available. For the user who does know > what is going on (or who can learn) that particular > tool/facility is likely to be far more useful in the long run > than any collection of "we know more about this than you do and > are here to protect you" tools. For what I think Gerv believes > is the more typical user (and he is probably right) such a tool > is, at worst, another feature like "display source" that will > never be used. > > If I have to copy a string and carry it to another tool, the > value of the approach goes down significantly, not just because > the inconvenience might discourage me from checking strings I > ought to check, but because the uncertainties of copy-and-paste > operations might yield false results. > > As a trivial, ASCII-only, example, if I see "rn" on a small > screen and in poor light, it would be a huge advantage to be > able to be able to get the browser to show me code points that > would tell me if I'm looking at U+006D or at U+0072 U+006E. > Similar examples for far more complex IDN cases should be > obvious. For that set of examples, the code point list is > likely to be a lot more useful than an A-label. There will > likely be other cases where the A-label (or the U-label if the > A-label is displayed) will be more useful. FWIW, such a > facility will, IMO, become even more important if we start > seeing wide deployment of non-trivial IRIs (and, for them, > %-encoded UTF-8 needs to be on the list of forms that can be > seen or obtained too). > > > > This is why I suggest that your mail is published as an > > extension of RFC 5895. > > I actually don't think it has much to do with 5895. Independent > of that, if others think it is useful enough, I could certainly > put it together either as an I-D that might lead to an RFC or > as an article for publication elsewhere. At least at this hour > of the night, I'd guess the latter might be more appropriate, if > only because the IETF and the RFC Series rarely go that far down > the path toward UI design. > > best, > john > > > > _______________________________________________ > Idna-update mailing list > Idna-update@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/idna-update > --90e6ba6135b8d1b11804b85c5c92 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable At the risk of jumping in at mid-stream, it occurs to me that John's id= ea below (show U-label, show A-label, show Unicode character identifiers) i= s a variant of the "show source" that some users will choose to d= o for web pages, or "show original" for display of all the extra = stuff that goes along with an email. Highlighting an FQDN and having a drop= down opportunity to display it in various ways might be one way to help us= ers signal this desire. Obviously, the u-label display won't work if th= e fonts aren't available.

vint


On Tue, Fe= b 7, 2012 at 1:35 AM, John C Klensin <klensin@jck.com> wrote:


--On Tuesday, February 07, 2012 02:02 +0100 "J-F C. Morfin"
<jfc@morfin.org&= gt; wrote:

> At 21:24 06/02/2012, John C Klensin wrote:
>> Gerv,
>
> John,
>
> as long as we are talking of a Mozilla-IPI (International
> Plug-In) that can be used with a transparent Firefox and every
> other browser when in transparent mode, so we get the same
> result whatever the browser or we can use whatever other IPI
> approved by the local ISOC Chapter, ICANN, the national
> university association, ZDNet, the national ccTLD, etc. with
> Firefox there is no problem with IUsers.

I actually wasn't talking about that. =A0My reason is one of thos= e
in which we may converge in the extreme case even if we disagree
on most of the details (I'm not sure we do).

I'm quite certain that there is no perfect solution to the
problems and alternatives to drive Gerv's policy (and other
policies in other browsers). =A0 I think that the classic remedy
of "a good compromise is one that makes everyone equally
unhappy" is not a good solution in this type of human interface
situation. =A0 And, while I really like the idea of Gerv and his
colleagues that every version of Firefox, on every platform and
in every language adaptation, should behave the same way wrt
IDNs, I'm not sure that is the most important objective. =A0In
particular, I think it is possible that ability to localize and
to adjust to different user usage pattern may be more important.

I'm also really, really afraid of the possible consequences of
widespread appearance appearance of "????" or other "tried t= o
display that and couldn't" situations. =A0I think that many of the=
people who are concerned about confusion among characters are
paying too little attention to that one.

As a result, my preference is that:

(1) Different browsers try the ideas that they think will work
best so that we can all compare, ideas that are clearly good can
gradually spread, and, if it turns out that there are only
tradeoffs, users can make choices based on what suits their
needs and matches their taste. =A0Coming up with a universal
solution (or even a clear definition of a "transparent mode") at<= br> this point seems to me to require knowledge that none of us
really have, independent of whether our guesses and hypotheses
agree or disagree.

(2) I deliberately didn't mention it in my long note but, from a
UI design standpoint, I'd like to see Firefox do two additional
things.

One is to provide a switch that permits a user to say "I think
I'm smarter than you are and am willing to take responsibility
for that belief and its consequences". =A0If set in this case (it
should obviously be off by default), it should simply disable
all of the "display algorithm" stuff, causing the browser to
display whatever it can in native character form. =A0From my point
of view, similar switches in other browsers to disable _their_
algorithms and approaches to the problem would be a good idea
too. =A0For reasons that I think I understand, I don't expect
Mozilla to provide that switch (or perhaps to provide it and
make it hard for any but the most sophisticated users to find),
but I still think it would be a good idea.

The second, and even more important, is that I believe the
browser should provide a very accessible, very easy-to-use,
transcoder for these labels. =A0The best UI may differ among
browsers and platforms, but, as an example for desktop machines,
I'd like to be able to right-click on a domain name or label or
even highlighted/ selected string and have all three of U-label
form, A-label form, and a list of Unicode code points (in U+NNNN
or \u'NNNN' form) easily available. =A0For the user who does know what is going on (or who can learn) that particular
tool/facility is likely to be far more useful in the long run
than any collection of "we know more about this than you do and
are here to protect you" tools. =A0For what I think Gerv believes
is the more typical user (and he is probably right) such a tool
is, at worst, another feature like "display source" that will
never be used.

If I have to copy a string and carry it to another tool, the
value of the approach goes down significantly, not just because
the inconvenience might discourage me from checking strings I
ought to check, but because the uncertainties of copy-and-paste
operations might yield false results.

As a trivial, ASCII-only, example, if I see "rn" on a small
screen and in poor light, it would be a huge advantage to be
able to be able to get the browser to show me code points that
would tell me if I'm looking at U+006D or at U+0072 U+006E.
Similar examples for far more complex IDN cases should be
obvious. =A0For that set of examples, the code point list is
likely to be a lot more useful than an A-label. =A0There will
likely be other cases where the A-label (or the U-label if the
A-label is displayed) will be more useful. =A0FWIW, such a
facility will, IMO, become even more important if we start
seeing wide deployment of non-trivial IRIs (and, for them,
%-encoded UTF-8 needs to be on the list of forms that can be
seen or obtained too).


> This is why I suggest that your mail is published as an
> extension of RFC 5895.

I actually don't think it has much to do with 5895. =A0Independen= t
of that, if others think it is useful enough, I could certainly
put it together either as an I-D =A0that might lead to an RFC or
as an article for publication elsewhere. =A0 At least at this hour
of the night, I'd guess the latter might be more appropriate, if
only because the IETF and the RFC Series rarely go that far down
the path toward UI design.

best,
=A0 =A0john



_______________________________________________
Idna-update mailing list
Idna-update@alvestrand.no<= br> http://www.alvestrand.no/mailman/listinfo/idna-update

--90e6ba6135b8d1b11804b85c5c92-- From jfc@morfin.org Wed Feb 8 03:43:38 2012 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0B3A21F857F for ; Wed, 8 Feb 2012 03:43:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.033 X-Spam-Level: X-Spam-Status: No, score=-0.033 tagged_above=-999 required=5 tests=[AWL=-0.635, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOoZQr3Orl9V for ; Wed, 8 Feb 2012 03:43:37 -0800 (PST) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id 87E0B21F857A for ; Wed, 8 Feb 2012 03:43:37 -0800 (PST) Received: from 36.51-227-89.dsl.completel.net ([89.227.51.36]:63352 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1Rv5vq-00031h-Lj; Wed, 08 Feb 2012 03:43:27 -0800 Message-Id: <7.0.1.0.2.20120208120919.0cb2dac8@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 08 Feb 2012 12:44:39 +0100 To: Vint Cerf ,John C Klensin From: "J-F C. Morfin" In-Reply-To: References: <7.0.1.0.2.20120207015026.0cb2e508@jefsey.com> <56D46FA55B3A284F63A6FC0A@PST.JCK.COM> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_626179027==.ALT" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - morfin.org X-Source: X-Source-Args: X-Source-Dir: Cc: Gervase Markham , idna-update@alvestrand.no, iucg@ietf.org, iutf@iutf.org Subject: Re: [iucg] Proposed new Firefox IDN display algorithm X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 11:43:38 -0000 --=====================_626179027==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 10:25 07/02/2012, Vint Cerf wrote: >At the risk of jumping in at mid-stream, it occurs to me that John's >idea below (show U-label, show A-label, show Unicode character >identifiers) is a variant of the "show source" that some users will >choose to do for web pages, or "show original" for display of all >the extra stuff that goes along with an email. Highlighting an FQDN >and having a drop down opportunity to display it in various ways >might be one way to help users signal this desire. Obviously, the >u-label display won't work if the fonts aren't available. Excellent remark. The only thing we need now is for the users to be able to send and receieve in a similar way (options or options on a TLD list with a default choosable option) non-filtered strings in the case of usages or TLDs not respecting IDNA2008 restrictions, like initially documented by ".su", a position that will most probably be adopted by most non-ICANN bound TLD managers (ccTLDs, private networks). jfc >vint > > >On Tue, Feb 7, 2012 at 1:35 AM, John C Klensin ><klensin@jck.com> wrote: > > >--On Tuesday, February 07, 2012 02:02 +0100 "J-F C. Morfin" ><jfc@morfin.org> wrote: > > > At 21:24 06/02/2012, John C Klensin wrote: > >> Gerv, > > > > John, > > > > as long as we are talking of a Mozilla-IPI (International > > Plug-In) that can be used with a transparent Firefox and every > > other browser when in transparent mode, so we get the same > > result whatever the browser or we can use whatever other IPI > > approved by the local ISOC Chapter, ICANN, the national > > university association, ZDNet, the national ccTLD, etc. with > > Firefox there is no problem with IUsers. > >I actually wasn't talking about that. My reason is one of those >in which we may converge in the extreme case even if we disagree >on most of the details (I'm not sure we do). > >I'm quite certain that there is no perfect solution to the >problems and alternatives to drive Gerv's policy (and other >policies in other browsers). I think that the classic remedy >of "a good compromise is one that makes everyone equally >unhappy" is not a good solution in this type of human interface >situation. And, while I really like the idea of Gerv and his >colleagues that every version of Firefox, on every platform and >in every language adaptation, should behave the same way wrt >IDNs, I'm not sure that is the most important objective. In >particular, I think it is possible that ability to localize and >to adjust to different user usage pattern may be more important. > >I'm also really, really afraid of the possible consequences of >widespread appearance appearance of "????" or other "tried to >display that and couldn't" situations. I think that many of the >people who are concerned about confusion among characters are >paying too little attention to that one. > >As a result, my preference is that: > >(1) Different browsers try the ideas that they think will work >best so that we can all compare, ideas that are clearly good can >gradually spread, and, if it turns out that there are only >tradeoffs, users can make choices based on what suits their >needs and matches their taste. Coming up with a universal >solution (or even a clear definition of a "transparent mode") at >this point seems to me to require knowledge that none of us >really have, independent of whether our guesses and hypotheses >agree or disagree. > >(2) I deliberately didn't mention it in my long note but, from a >UI design standpoint, I'd like to see Firefox do two additional >things. > >One is to provide a switch that permits a user to say "I think >I'm smarter than you are and am willing to take responsibility >for that belief and its consequences". If set in this case (it >should obviously be off by default), it should simply disable >all of the "display algorithm" stuff, causing the browser to >display whatever it can in native character form. From my point >of view, similar switches in other browsers to disable _their_ >algorithms and approaches to the problem would be a good idea >too. For reasons that I think I understand, I don't expect >Mozilla to provide that switch (or perhaps to provide it and >make it hard for any but the most sophisticated users to find), >but I still think it would be a good idea. > >The second, and even more important, is that I believe the >browser should provide a very accessible, very easy-to-use, >transcoder for these labels. The best UI may differ among >browsers and platforms, but, as an example for desktop machines, >I'd like to be able to right-click on a domain name or label or >even highlighted/ selected string and have all three of U-label >form, A-label form, and a list of Unicode code points (in U+NNNN >or \u'NNNN' form) easily available. For the user who does know >what is going on (or who can learn) that particular >tool/facility is likely to be far more useful in the long run >than any collection of "we know more about this than you do and >are here to protect you" tools. For what I think Gerv believes >is the more typical user (and he is probably right) such a tool >is, at worst, another feature like "display source" that will >never be used. > >If I have to copy a string and carry it to another tool, the >value of the approach goes down significantly, not just because >the inconvenience might discourage me from checking strings I >ought to check, but because the uncertainties of copy-and-paste >operations might yield false results. > >As a trivial, ASCII-only, example, if I see "rn" on a small >screen and in poor light, it would be a huge advantage to be >able to be able to get the browser to show me code points that >would tell me if I'm looking at U+006D or at U+0072 U+006E. >Similar examples for far more complex IDN cases should be >obvious. For that set of examples, the code point list is >likely to be a lot more useful than an A-label. There will >likely be other cases where the A-label (or the U-label if the >A-label is displayed) will be more useful. FWIW, such a >facility will, IMO, become even more important if we start >seeing wide deployment of non-trivial IRIs (and, for them, >%-encoded UTF-8 needs to be on the list of forms that can be >seen or obtained too). > > > > This is why I suggest that your mail is published as an > > extension of RFC 5895. > >I actually don't think it has much to do with 5895. Independent >of that, if others think it is useful enough, I could certainly >put it together either as an I-D that might lead to an RFC or >as an article for publication elsewhere. At least at this hour >of the night, I'd guess the latter might be more appropriate, if >only because the IETF and the RFC Series rarely go that far down >the path toward UI design. > >best, > john > > > >_______________________________________________ >Idna-update mailing list >Idna-update@alvestrand.no >http://www.alvestrand.no/mailman/listinfo/idna-update > > >_______________________________________________ >Idna-update mailing list >Idna-update@alvestrand.no >http://www.alvestrand.no/mailman/listinfo/idna-update --=====================_626179027==.ALT Content-Type: text/html; charset="us-ascii" At 10:25 07/02/2012, Vint Cerf wrote:
At the risk of jumping in at mid-stream, it occurs to me that John's idea below (show U-label, show A-label, show Unicode character identifiers) is a variant of the "show source" that some users will choose to do for web pages, or "show original" for display of all the extra stuff that goes along with an email. Highlighting an FQDN and having a drop down opportunity to display it in various ways might be one way to help users signal this desire. Obviously, the u-label display won't work if the fonts aren't available.

Excellent remark. The only thing we need now is for the users to be able to send and receieve in a similar way (options or options on a TLD list with a default choosable option) non-filtered strings in the case of usages or TLDs not respecting IDNA2008 restrictions, like initially documented by ".su", a position that will most probably be adopted by most non-ICANN bound TLD managers (ccTLDs, private networks).
jfc




vint


On Tue, Feb 7, 2012 at 1:35 AM, John C Klensin <klensin@jck.com> wrote:


--On Tuesday, February 07, 2012 02:02 +0100 "J-F C. Morfin"
<jfc@morfin.org> wrote:

> At 21:24 06/02/2012, John C Klensin wrote:
>> Gerv,
>
> John,
>
> as long as we are talking of a Mozilla-IPI (International
> Plug-In) that can be used with a transparent Firefox and every
> other browser when in transparent mode, so we get the same
> result whatever the browser or we can use whatever other IPI
> approved by the local ISOC Chapter, ICANN, the national
> university association, ZDNet, the national ccTLD, etc. with
> Firefox there is no problem with IUsers.

I actually wasn't talking about that.  My reason is one of those
in which we may converge in the extreme case even if we disagree
on most of the details (I'm not sure we do).

I'm quite certain that there is no perfect solution to the
problems and alternatives to drive Gerv's policy (and other
policies in other browsers).   I think that the classic remedy
of "a good compromise is one that makes everyone equally
unhappy" is not a good solution in this type of human interface
situation.   And, while I really like the idea of Gerv and his
colleagues that every version of Firefox, on every platform and
in every language adaptation, should behave the same way wrt
IDNs, I'm not sure that is the most important objective.  In
particular, I think it is possible that ability to localize and
to adjust to different user usage pattern may be more important.

I'm also really, really afraid of the possible consequences of
widespread appearance appearance of "????" or other "tried to
display that and couldn't" situations.  I think that many of the
people who are concerned about confusion among characters are
paying too little attention to that one.

As a result, my preference is that:

(1) Different browsers try the ideas that they think will work
best so that we can all compare, ideas that are clearly good can
gradually spread, and, if it turns out that there are only
tradeoffs, users can make choices based on what suits their
needs and matches their taste.  Coming up with a universal
solution (or even a clear definition of a "transparent mode") at
this point seems to me to require knowledge that none of us
really have, independent of whether our guesses and hypotheses
agree or disagree.

(2) I deliberately didn't mention it in my long note but, from a
UI design standpoint, I'd like to see Firefox do two additional
things.

One is to provide a switch that permits a user to say "I think
I'm smarter than you are and am willing to take responsibility
for that belief and its consequences".  If set in this case (it
should obviously be off by default), it should simply disable
all of the "display algorithm" stuff, causing the browser to
display whatever it can in native character form.  From my point
of view, similar switches in other browsers to disable _their_
algorithms and approaches to the problem would be a good idea
too.  For reasons that I think I understand, I don't expect
Mozilla to provide that switch (or perhaps to provide it and
make it hard for any but the most sophisticated users to find),
but I still think it would be a good idea.

The second, and even more important, is that I believe the
browser should provide a very accessible, very easy-to-use,
transcoder for these labels.  The best UI may differ among
browsers and platforms, but, as an example for desktop machines,
I'd like to be able to right-click on a domain name or label or
even highlighted/ selected string and have all three of U-label
form, A-label form, and a list of Unicode code points (in U+NNNN
or \u'NNNN' form) easily available.  For the user who does know
what is going on (or who can learn) that particular
tool/facility is likely to be far more useful in the long run
than any collection of "we know more about this than you do and
are here to protect you" tools.  For what I think Gerv believes
is the more typical user (and he is probably right) such a tool
is, at worst, another feature like "display source" that will
never be used.

If I have to copy a string and carry it to another tool, the
value of the approach goes down significantly, not just because
the inconvenience might discourage me from checking strings I
ought to check, but because the uncertainties of copy-and-paste
operations might yield false results.

As a trivial, ASCII-only, example, if I see "rn" on a small
screen and in poor light, it would be a huge advantage to be
able to be able to get the browser to show me code points that
would tell me if I'm looking at U+006D or at U+0072 U+006E.
Similar examples for far more complex IDN cases should be
obvious.  For that set of examples, the code point list is
likely to be a lot more useful than an A-label.  There will
likely be other cases where the A-label (or the U-label if the
A-label is displayed) will be more useful.  FWIW, such a
facility will, IMO, become even more important if we start
seeing wide deployment of non-trivial IRIs (and, for them,
%-encoded UTF-8 needs to be on the list of forms that can be
seen or obtained too).


> This is why I suggest that your mail is published as an
> extension of RFC 5895.

I actually don't think it has much to do with 5895.  Independent
of that, if others think it is useful enough, I could certainly
put it together either as an I-D  that might lead to an RFC or
as an article for publication elsewhere.   At least at this hour
of the night, I'd guess the latter might be more appropriate, if
only because the IETF and the RFC Series rarely go that far down
the path toward UI design.

best,
   john



_______________________________________________
Idna-update mailing list
Idna-update@alvestrand.no
http://www.alvestrand.no/mailman/listinfo/idna-update


_______________________________________________
Idna-update mailing list
Idna-update@alvestrand.no
http://www.alvestrand.no/mailman/listinfo/idna-update
--=====================_626179027==.ALT-- From gerv@mozilla.org Fri Feb 17 07:52:53 2012 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F6E721F87E1 for ; Fri, 17 Feb 2012 07:52:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8no84q8E1IA for ; Fri, 17 Feb 2012 07:52:53 -0800 (PST) Received: from dm-mail03.mozilla.org (dm-mail03.mozilla.org [63.245.208.213]) by ietfa.amsl.com (Postfix) with ESMTP id B80D221F87B8 for ; Fri, 17 Feb 2012 07:52:52 -0800 (PST) Received: from [192.168.0.101] (93.243.187.81.in-addr.arpa [81.187.243.93]) (Authenticated sender: gerv@mozilla.org) by dm-mail03.mozilla.org (Postfix) with ESMTP id 67B274AEDC2; Fri, 17 Feb 2012 07:52:51 -0800 (PST) Message-ID: <4F3E77D1.8080306@mozilla.org> Date: Fri, 17 Feb 2012 15:52:49 +0000 From: Gervase Markham User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0) Gecko/20120118 Thunderbird/10.0 MIME-Version: 1.0 To: John C Klensin References: <7.0.1.0.2.20120207015026.0cb2e508@jefsey.com> <56D46FA55B3A284F63A6FC0A@PST.JCK.COM> In-Reply-To: <56D46FA55B3A284F63A6FC0A@PST.JCK.COM> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: idna-update@alvestrand.no, iucg@ietf.org, "J-F C. Morfin" , iutf@iutf.org Subject: Re: [iucg] Proposed new Firefox IDN display algorithm X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 15:52:53 -0000 On 07/02/12 06:35, John C Klensin wrote: > (2) I deliberately didn't mention it in my long note but, from a > UI design standpoint, I'd like to see Firefox do two additional > things. > > One is to provide a switch that permits a user to say "I think > I'm smarter than you are and am willing to take responsibility > for that belief and its consequences". At the moment, such a switch exists - sort of. You can just add every TLD to the whitelist. We could have a global switch if it were hidden away in about:config; the issue here is that if such a switch exists, then people might switch it on. ;-) > The second, and even more important, is that I believe the > browser should provide a very accessible, very easy-to-use, > transcoder for these labels. I can see why you want this, although I suspect that the target audience would be so small that the Firefox team would balk at adding a new feature for it. Every feature has initial and ongoing costs, after all. I see your analogy to View Source, but that's been a great tool in proving that the web is readable, hackable and remixable - the usage of this feature would be a lot more obscure and specialized. > As a trivial, ASCII-only, example, if I see "rn" on a small > screen and in poor light, it would be a huge advantage to be > able to be able to get the browser to show me code points that > would tell me if I'm looking at U+006D or at U+0072 U+006E. If this is your problem, then we have a greater UI problem than providing a way for people to see the hex codes behind each character! Gerv From jfc@morfin.org Wed Feb 22 09:16:51 2012 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE17021F8729 for ; Wed, 22 Feb 2012 09:16:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.227 X-Spam-Level: X-Spam-Status: No, score=-0.227 tagged_above=-999 required=5 tests=[AWL=-0.229, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhzuX6CnBeV3 for ; Wed, 22 Feb 2012 09:16:46 -0800 (PST) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id D272521F85F7 for ; Wed, 22 Feb 2012 09:16:46 -0800 (PST) Received: from 97.41-227-89.dsl.completel.net ([89.227.41.97]:59574 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1S0Fo3-0007Bq-00; Wed, 22 Feb 2012 09:16:43 -0800 Message-Id: <7.0.1.0.2.20120222175827.0622bb70@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 22 Feb 2012 18:18:52 +0100 To: Naela Sarras ,"vip@icann.org" From: "J-F C. Morfin" In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_571586025==.ALT" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - morfin.org X-Source: X-Source-Args: X-Source-Dir: Cc: "idna-update@alvestrand.no work" , iucg@ietf.org Subject: Re: [iucg] [vip] Final Integrated Issues Report and Project Plan for Next Steps Now Posted X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 17:16:51 -0000 --=====================_571586025==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 22:55 21/02/2012, Naela Sarras wrote: >Dear Colleagues, > >The final Integrated Issues Report has been posted. In addition, >the draft VIP Project Plan for the next steps has been posted for >public comment. > >http://www.icann.org/en/announcements/announcement-20feb12-en.htm >http://www.icann.org/en/public-comment/idn-vip-proposed-project-plan-20feb12-en.htm > >Both documents will be discussed at the IDN Variant Issues Project >Session during the ICANN Costa Rica Meeting, 11-16 March 2012. > >Best regards, > >Naela Sarras >ICANN Dear Naella, is this list still active for disscussion over the Very Impossible Project (VIP) issue? If yes, what I hope, are new venues allowed in the debate (like Internet extended architectural frameworks able to support variants off the shelves)? Thank you jfc --=====================_571586025==.ALT Content-Type: text/html; charset="us-ascii" At 22:55 21/02/2012, Naela Sarras wrote:
Dear Colleagues,

The final Integrated Issues Report has been posted.  In addition, the draft VIP Project Plan for the next steps has been posted for public comment.

http://www.icann.org/en/announcements/announcement-20feb12-en.htm
http://www.icann.org/en/public-comment/idn-vip-proposed-project-plan-20feb12-en.htm

Both documents will be discussed at the IDN Variant Issues Project Session during the ICANN Costa Rica Meeting, 11-16 March 2012.

Best regards,

Naela Sarras
ICANN

Dear Naella,

is this list still active for disscussion over the Very Impossible Project (VIP) issue?
If yes, what I hope, are new venues allowed in the debate (like Internet extended architectural frameworks able to support variants off the shelves)?

Thank you
jfc
--=====================_571586025==.ALT-- From jefsey@jefsey.com Tue Feb 28 09:51:36 2012 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7C1721F86F0; Tue, 28 Feb 2012 09:51:35 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -101.724 X-Spam-Level: X-Spam-Status: No, score=-101.724 tagged_above=-999 required=5 tests=[AWL=0.875, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbfqVxuTpZcJ; Tue, 28 Feb 2012 09:51:34 -0800 (PST) Received: from m169.montage2.altserver.com (m169.montage2.altserver.com [72.34.52.169]) by ietfa.amsl.com (Postfix) with ESMTP id 10BA521F86EB; Tue, 28 Feb 2012 09:51:34 -0800 (PST) Received: from 221.134-227-89.dsl.completel.net ([89.227.134.221]:58792 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1S2RD1-0002vF-BC; Tue, 28 Feb 2012 09:51:31 -0800 Message-Id: <7.0.1.0.2.20120228182138.0e34d430@jefsey.com> Message-Id: <7.0.1.0.2.20120228180649.0e34d1a0@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 28 Feb 2012 18:54:29 +0100 To: iutf@iutf.org,"iucg@ietf.org" From: jefsey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: Cc: John C Klensin , "iab@iab.org IAB" , Vint Cerf , IESG Subject: [iucg] Internet+ double drafts X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 17:51:37 -0000 Documenting the IUI Interintelligibility stratum progresses, in parallel to Google+. 1. here are the two fundamental I_D published by the IUCG in a good cooperation spirit. They shows how the Internet+ extension does not affect the Internet IETF layers. The architectural framework: http://www.ietf.org/internet-drafts/draft-iucg-internet-plus-08.txt This memo acknowledges the change of scale in network and people centricities within the whole digital ecosystem. It shows how the Internet technology can sustain the resulting network and societal effects in scaling itself from the end to end Internet to a fringe to fringe fully optional and compatible Internet+ which strictly conforms to the Internet architecture and RFCs. It introduces the Internet+ architectural framework and the IUTF to document it. It explores a transition that can be seamlessly immediate and will probably start a complete review and extension of the Internet schemas towards the semiotic Internet (Intersem). Where to document this architecture: http://www.ietf.org/internet-drafts/draft-iucg-iutf-tasks-00.txt The Intelligent Use Task Force (IUTF) has responsibility for organizing Dedicated Interest Groups (DIG) to research, document and validate solutions in the area of Intelligent Use Interfaces (IUI) between the various components of the whole digital ecosystem (WDE), the resulting intelligent global network (IGNet), the diversity of on-line facilitation services that their IUI and IGNet may bring to people and machines. This document describes the guidelines and procedures for the formation, operations, experimentations and publications of IUTF Dedicated Interest Groups and their internal and external relations with other SDOs (Standardization and Documentation Organizations). Its publication as an IETF Draft is part of the IUCG liaison. 2. The next step should be an I_D on the "intertest", i.e. the constraints to respect and the rules to apply when using the internal Internet as its own test-bed. This Draft will also be presented as an indvidual submission but will quote different previous I_Ds, RFCs, and other documents and will be introduced to an IETF general review. 3. The IUTF will support the InterPLUS architectural research, evolution, and documentation, as initiated at the IUCG, only because it seems the most conceptually advanced. This is not therefore an endorsement, only an experimentation to gain experience for NETIX (network executive tasks internet command system) definition. 4. The InterPLUS designers have not yet decided of the final software architecture. However they consider proposing two approaches : one genuinely designed which would first use an embeded DNS logic and further on a dedicated ML-DNS/DDDS logic, and one that could be implemented as a BIND based OPES. jfc PS. Some heart surgery has tired me, so I will continue this work at a slower path.