Discussion on RFC 3023 initiated by W3C TAG

[Andrew Hately <hately@us.ibm.com>]

FYI... I've been following this discussion
and it does not seem to be getting traction, but I thought the rest of
the UDDI implementors should be aware that the W3C TAG is reviewing RFC3023
behavior.

I think we can continue to assume that
what we have specified is OK for now but we need to follow this issue.

Andrew Hately
IBM Austin
UDDI Development, Emerging Technologies 
Lotus Notes: Andrew Hately/Austin/IBM@IBMUS
Internet: hately@us.ibm.com
(512) 838-2866,  t/l 678-2866

----- Forwarded by Andrew
Hately/Austin/IBM on 09/24/2003 11:09 AM -----

Yes, the tag list is public (not all
W3C lists are, so it pays to check).  The link to the entry for Tim's
note is at [1], and as you can see from the URL it's in the public part
of the W3C Archive space.  Feel free to forward it.  Anyone who
wants to contribute to the list should probably look at [2] first, so you
might want to pass on that hint. Thanks for checking.

[1] http://lists.w3.org/Archives/Public/www-tag/2003Sep/0042.html
[2] http://www.w3.org/2001/tag/#mail-policy

------------------------------------------------------------------
Noah Mendelsohn                
          
------------------------------------------------------------------






Is this from a publicly readable mailing
list and is it OK to forward this discussion to the OASIS UDDI TC?  It
would be good for that TC to be aware of possible churn around SOAP message
parsing with respect to the HTTP header handling.


Andrew Hately





For those who don't follow the W3C Tag....

------------------------------------------------------------------
Noah Mendelsohn                
             Voice: 1-617-693-4036
IBM Corporation                
               Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------



----- Forwarded by Noah
Mendelsohn/Cambridge/IBM on 09/16/2003 01:54 PM -----

Tim Bray <tbray@textuality.com> Sent by: www-tag-request@w3.org 09/15/2003 08:16 PM

To:        "Simon St.Laurent" <simonstl@simonstl.com>, dan@dankohn.com, murata@hokkaido.email.ne.jp, WWW-Tag <www-tag@w3.org>         cc:        (bcc: Noah Mendelsohn/Cambridge/IBM)         Subject:        Can we revise RFC3023?

On the TAG telecon today, we were discussing our draft finding "Client
Handling of MIME Headers" 
(http://www.w3.org/2001/tag/doc/mime-respect.html), which grumbles about
the contents of RFC3023 with respect to charset handling.

I took an action item to ask 3023's authors if there was any chance to
revise what it says about the charset parameter; I think we have fairly
widespread agreement as to what needs to be done:

1. Deprecate text/* for anything that's in XML.  That's because it
forces the provider to provide a charset header, because in its absence
the receiver is required to assume either ASCII or 8859 depending on the
context, which has a very high probability of being wrong, which is 
irritating because if there were no charset header the client would have
an excellent chance of getting it right.  And forcing the server to
provide a charset= is wrong; see the next point.,

2. Deprecate the charset parameter for application/xml and 
application/*+xml.  I think that Roy would like to go far as to simply
outlaw it; I'd be fine with that too.  The reason is that the client
is 
almost certain to get it right, and will fail deterministically if it 
doesn't.  For the server, on the other hand, this is really hard to
get 
right, particularly with the introduction of various kinds of filters in
modern web servers.  And since the Web architecture and the XML spec
says that the server's claim has to be taken as authoritative, this is
really highly dysfunctional.  At the very least, it should be made
clear 
that nobody sending a media-type should send a charset for an XML 
media-type unless it REALLY REALLY KNOWS what it's sending, and in that
case should consider not sending it anyhow.

Makoto, Simon, Dan, any chance?  It's going to be kind of embarrassing
for TAG findings and the Webarch doc to be saying "don't do what this
RFC says".
-- 
Cheers, Tim Bray
         (ongoing fragmented essay: http://www.tbray.org/ongoing/)