interoperability testing

Mark Andrews marka at isc.org
Tue Jul 14 03:14:49 CEST 2009 

In message <D05FBD72-2C0A-4E10-B2C7-AAB14573CE55 at ca.afilias.info>, Joseph Yee w
rites:
> Speaking on my own (not for EAI group),
> 
> EAI has dependency on IDNA.  MTA (eg. Sendmail) needs to read the  
> domain of the recipient email, maps it to punycode before passing it 
> to DNS to resolve, in order to route message to the right place.  

	MTA's do NOT need it.  MUA may need it.  -t is only used when
	sendmail is running as a MUA not as a MTA.

> Similar to Apache, the web server, you can set your MTA to 'serve' to 
> a particular domain.  The app can run regardless how bad the domain 
> name broke the IDNA rules, or unmapped, just no one can reach your 
> service in convenient way.  The issue is the service's reachability 
> (not yet a dictionary word) via DNS.  No doubt a resolution issue.
> I guess IM/jabber is in similar situation too, but not sure.
> 
> Regards,
> Joseph
> 
> On 12-Jul-09, at 1:02 AM, Shawn Steele wrote:
> 
> > Re: email, so far EAI has avoided a dependency on the details of  =
> > IDNA, it's just UTF8.  I would expect that email would allow  =
> > unmapped names.  Specifically, the local part relies on servers to  =
> > do mapping, so requiring more for the domain would be odd IMO.
> > shawn
>
> > Sent from my HTC FUZE=99, a Windows Mobile=AE smartphone from AT&T
> >
> > -----Original Message-----
> > From: Erik van der Poel <erikv at google.com>
> > Sent: Saturday, July 11, 2009 5:43 PM
> > To: Eric Brunner-Williams <ebw at abenaki.wabanaki.net>
> > Cc: Paul Hoffman <phoffman at imc.org>; Gervase Markham  =
> 
> > <gerv at mozilla.org>; Shawn Steele <Shawn.Steele at microsoft.com>; idna-updat=
> e at alvestrand.no =
> 
> >  <idna-update at alvestrand.no>
> > Subject: Re: interoperability testing
> >
> >
> > Hi Eric,
> >
> > I'm not really sure how to respond, but we generally don't mention
> > APIs much in our IDNA "interoperability story". Until now, IDNA2003
> > has been quite clear, and so the APIs all implemented the same thing
> > (more or less), e.g. Microsoft's API(s), GNU's libidn, etc. With
> > IDNAbis, we may actually see two different kinds of APIs, one that is
> > more or less the same as IDNA2003 (with mappings) and one that does
> > not perform mappings, especially if the email specs specify U-labels
> > *and* the major vendors follow suit.
> >
> > Google Web Search's IDNA "interoperability story" would not be
> > centered on APIs, but on "wire formats" (for lack of a better term in
> > this wireless age). Specifically, we are extremely interested in the
> > HTML, HTTP and DNS wire formats. We study the browsers very closely,
> > and we mimic the major implementations unless there is a very good
> > reason to diverge. I should note that Google Web Search has two
> > "ends": the crawler end, which is as lenient as the most lenient major
> > implementations (including Opera), and the serving end, which is as
> > strict as we need to be for the browsers that are still being used
> > (i.e. we serve Punycode because MSIE6 does not support IDNA).
> >
> > The story for Chrome is probably quite similar (i.e. they look at the
> > major browsers). I'm less familiar with Google's email apps and IM
> > apps.
> >
> > Does this help at all?
> >
> > Erik
> >
> > On Sat, Jul 11, 2009 at 3:24 PM, Eric
> > Brunner-Williams<ebw at abenaki.wabanaki.net> wrote:
> >> Erik,
> >>
> >> Thanks for the comment. I actually ment "google" when I typed "search
> >> engine", then backspaced and wrote "database".
> >>
> >> The example, path names in a URL, via packet capture, would  =
> 
> >> interest me if
> >> it were 1989, and I was working on i18n in the *nix file system. I
> >> appreciate that you've offered this only as an example of what you  =
> 
> >> are doing
> >> with packet capture, using identical test sets and different  =
> 
> >> instances of
> >> the same (to a major release no.) browser, and an IDNA proximal  =
> 
> >> issue, but
> >> I'm still wondering what we really mean by interoperability.
> >>
> >> For a universe of values, two actually, the 2003 and the bis  =
> 
> >> universes,
> >> there is an interoperability "story" for resolution, not a lot  =
> 
> >> different
> >> from put $vendor_router in $test_harness, load with $config_files and
> >> $in_packet_streams and log $internal_state and $out_packet_streams.  =
> 
> >> The
> >> $edit_zonefile issues are similar to the router $config_files tests.
> >>
> >> If you, or Shawn, or Gerv, or Pete, could state what the  =
> 
> >> interoperability
> >> story is for your apps, something that doesn't end up with "and  =
> 
> >> then there
> >> was phishing, badness and thrashing", it would help me at least.
> >>
> >> I'd be happy with "this defines source code portability for some i18n
> >> related APIs for third-party developers for (I know this is a  =
> 
> >> stretch, but I
> >> did a lot of these) MUMBLEIX conformant applications." Then the
> >> interoperability at the API level would be a little clearer.
> >>
> >> Eric
> >>
> >> Erik van der Poel wrote:
> >>>
> >>> At Google, we have been working on a tool and set of test cases in
> >>> HTML that allow us to test the browsers. (We haven't spent time on  =
> 
> >>> IM,
> >>> email, databases, etc yet.) We don't use CSS in these test cases, so
> >>> the results don't show any CSS-dependent differences. Basically, we
> >>> start WireShark (previously known as Ethereal) and then we capture
> >>> packets sent from browsers when we load the HTML test files in them.
> >>> Then we save the captured file and generate reports that show
> >>> differences between, say, one browser on different operating  =
> 
> >>> systems,
> >>> or different browsers on the same operating system.
> >>>
> >>> For example, we can now clearly see the difference between Firefox 2
> >>> and 3 in the handling of non-ASCII text in the path part of the URL.
> >>> (Firefox 2 sends it in the original encoding of the HTML, while
> >>> Firefox 3 sends it in UTF-8.) We also test every ASCII value  =
> 
> >>> (0..127)
> >>> in every part of the URL. We look at both DNS and HTTP packets.
> >>>
> >>> The results are not quite ready for publication. We will probably  =
> 
> >>> send
> >>> them to the browser developers first, and then to spec writers and
> >>> other interested folks.
> >>>
> >>> Erik
> >>>
> >>> On Sat, Jul 11, 2009 at 10:32 AM, Eric
> >>> Brunner-Williams<ebw at abenaki.wabanaki.net> wrote:
> >>>
> >>>>
> >>>> I'm not sure there is a sensible single definition of IDNAbis
> >>>> interoperation by multiple implementations. I'm interested if one  =
> 
> >>>> exists
> >>>> for IDNA2003.
> >>>>
> >>>> If one were to automate a test for two or more instances of a  =
> 
> >>>> browser,
> >>>> possibly different snapshots of the same implementation, having  =
> 
> >>>> common
> >>>> specification, variation in css handling between the two or more
> >>>> versions could result in "difference determined by test".
> >>>>
> >>>> We are fairly safe when we ask if the resolution narrative is
> >>>> indifferent to which of {bind8, bind9, ...} instances of and test
> >>>> configurations of caching and authoritative resolvers.
> >>>>
> >>>> We are also fairly safe when we ask if the call and return  =
> 
> >>>> narrative of
> >>>> API use is portable within some framework of source code  =
> 
> >>>> portability, if
> >>>> APIs are within the scope of interoperability and multiple  =
> 
> >>>> independent
> >>>> implementations.
> >>>>
> >>>> How do the {IM,email,browser,database,...} application implementors
> >>>> propose to define meaningful functional interoperation between  =
> 
> >>>> any two
> >>>> or more independent implementations of their applications, or  =
> 
> >>>> across any
> >>>> test configuration of similar or dissimilar applications?
> >>>>
> >>>> Eric
> >>>>
> >>>
> >>>
> >>>
> >>
> >>
> >
> > _______________________________________________
> > Idna-update mailing list
> > Idna-update at alvestrand.no
> > http://www.alvestrand.no/mailman/listinfo/idna-update
> 
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org

More information about the Idna-update mailing list