Discussion on RFC 3023 initiated by W3C TAG

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: 

(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 <>

Sent by: 

09/15/2003 08:16 PM

        

        To:
       "Simon St.Laurent" <>,
, , WWW-Tag <>

        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/)