charset use in SOAP 1.2

I'm browsing the final spec of SOAP 1.2 Primer
http://www.w3.org/TR/2003/PR-soap12-part0-20030507/
and I have two questions. 

Near
http://www.w3.org/TR/2003/PR-soap12-part0-20030507/#L26866
	(thank you, Addision, for the pointer)
it reads:

 > When placing SOAP messages in HTTP bodies, the HTTP Content-type header 
 > must be chosen as "application/soap+xml". (The optional charset parameter, 
 > which can take the value of "utf-8" or "utf-16", is shown in this example, 
 > but if it is absent the character set rules for freestanding [XML 1.0] apply to 
 > the body of the HTTP request.)

The note in the paren seems to be saying that only UTF-8 and UTF-16
are the valid encodings that can be used in SOAP (over HTTP).  Does anyone
know if this is their intent, and if so, why?


On the other hand, SOAP-over-SMTP examples
http://www.w3.org/TR/2003/PR-soap12-part0-20030507/#Example14
http://www.w3.org/TR/2003/PR-soap12-part0-20030507/#Example31
			(This is actually for Exampl 15.)
do not use the charset attribute in the Content-Type header.  According to
Section 5.2 of RFC 2045
http://www.ietf.org/rfc/rfc2045.txt?number=2045
lack of charset info means US-ASCII.  Perhaps one can argue that the US-ASCII 
default only applies to text/* content, and application/soap+xml has a different rule,
which I may have overlooked.
But I also notice that both examples lack a Content-Transfer-Encoding header.
Section 6.1 of RFC 2045 also mentions that lack of Content-Transfer-Encoding
header means 7-bit channel.  Yet the body part in both examples contains
non-ASCII characters in the <n:name> element, which probably requires 8bit
channel or some sort of transfer encoding.

Is this an over-sight that we should point out, or am I misunderstanding 
something?


T. "Kuro" Kurosaka
Internationalization Architect
teruhiko.kurosaka@iona.com
-------------------------------------------------------
IONA Technologies
2350 Mission College Blvd. Suite 650
Santa Clara, CA 95054
Tel: (408) 350 9684/9500 
Fax: (408) 350 9501
-------------------------------------------------------
Making Software Work Together TM

Received on Thursday, 29 May 2003 19:43:40 UTC