<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=utf-8">
<META content="MSHTML 6.00.5730.11" name=GENERATOR></HEAD>
<BODY style="MARGIN: 4px 4px 1px; FONT: 10pt Tahoma">
<DIV>Good spotting Dave.</DIV>
<DIV> </DIV>
<DIV>This is fixed now in the TapirDotNET implementation of Tapir.</DIV>
<DIV>I have updated the HerbIMI TapirDotNET implementation at <A href="http://lsid.herbimi.info/TapirDotNET/tapir.aspx/herbIMI">http://lsid.herbimi.info/TapirDotNET/tapir.aspx/herbIMI</A></DIV>
<DIV>So if you could like to check this provider, I would be interested in your results.</DIV>
<DIV> </DIV>
<DIV>Kevin<BR><BR>>>> "Dave Vieglais" <vieglais@ku.edu> 9/11/2007 7:59 a.m. >>><BR></DIV>
<DIV style="COLOR: #000000">Hi Everyone,<BR>I've come across a minor issue with some existing TAPIR installations<BR>that should be easily fixed and will likely save some frustrations<BR>down the road.<BR><BR>The TAPIR spec (<A href="http://www.tdwg.org/dav/subgroups/tapir/1.0/docs/TAPIRSpecification_2007-07-18.html#toc16)">http://www.tdwg.org/dav/subgroups/tapir/1.0/docs/TAPIRSpecification_2007-07-18.html#toc16)</A><BR>indicates a response Content-type of "text/xml". RFC 3023<BR>(<A href="http://www.ietf.org/rfc/rfc3023.txt)">http://www.ietf.org/rfc/rfc3023.txt)</A> indicates that in this case,<BR>when no "charset" parameter is specified in the HTTP response header,<BR>the implied character encoding of the response document is "us-ascii"<BR>(see s8.5).<BR><BR>so for example:<BR><BR>Good:<BR> response header = Content-type: text/xml; charset="utf-8"<BR><BR> response document signature = <?xml version="1.0" encoding="utf-8"?><BR><BR>result = document is assumed to be UTF-8<BR><BR>Not so good:<BR> response header = Content-type: text/xml<BR><BR> response document signature = <?xml version="1.0" encoding="utf-8"?><BR><BR>result = document is assumed to be us-ascii<BR><BR><BR>All TAPIR installations that I've examined so far do not set a charset<BR>value, and hence the character encoding of "us-ascii" is assumed by<BR>the consumer application, which is likely to cause some issues for<BR>consumer applications. This was also a significant issue for DiGIR<BR>provider installations.<BR><BR>The solution is likely to be quite simple, and there seems to be two<BR>basic options:<BR><BR>1. Configure the webserver / application to insert a charset value of<BR>"UTF-8" to avoid the consumer falling back to the default of us-ascii.<BR><BR>or<BR><BR>2. Return a Content-type of "Application/xml" or one of its subtypes.<BR>In this case RFC 3023 indicates the default character encoding should<BR>be assumed to be UTF-8.<BR><BR>Note that simply specifying the content type does not automatically<BR>make the response properly encoded - it is still up to the web<BR>application (TAPIR in this case) to ensure that the output stream is<BR>actually UTF-8 encoded.<BR><BR>regards,<BR> Dave V.<BR>_______________________________________________<BR>tdwg-tapir mailing list<BR>tdwg-tapir@lists.tdwg.org<BR><A href="http://lists.tdwg.org/mailman/listinfo/tdwg-tapir">http://lists.tdwg.org/mailman/listinfo/tdwg-tapir</A><BR></DIV></BODY></HTML>