- From: Martin Duerst <duerst@w3.org>
- Date: Thu, 04 Dec 2003 14:28:11 -0500
- To: Mark Nottingham <mark.nottingham@bea.com>
- Cc: public-ietf-w3c@w3.org, "Xml-Dist-App@W3. Org" <xml-dist-app@w3.org>
At 16:18 03/12/03 -0800, Mark Nottingham wrote: >Speaking personally, > >>- public-ietf-w3c@w3.org is a coordination list, not necessarily for >> direct technical discussion. If the conclusion that you have come >> to is that you need to register a new Media Type, then I think >> you should just go forward and do that via the usual channels, >> and assure it gets reviewed e.g. on ietf-types@iana.org. > >Understood; there was a desire to do it 'by the numbers' and make sure >there was awareness of this at the proper places in the W3C. My >anticipation would be that ietf-types is the next step. Very good. Making various lists aware of the issue is never a bad idea. But as I said, don't expect much feedback here, just go on to ietf-types@iana.org. >>- I have read "resolve the URI to insert binary characters" below. >> This is rather worrying, because to me it sounds like "square >> circles". I have looked at the actual Miffy spec [3], and >> have seen similar confusing language. I haven't seen a worked-out >> example that would allow me to propose more precise language. > >[...] > >>>Note that a specification is being prepared that allows for the use of a >>>similar "resolve the URI to insert binary characters" idiom in non-SOAP >>>scenarios. > >I think our intent here was closer to "use URIs to obtain representations >that are included into the XML document with an encoding like base64 to >assure that it remains well-formed." SVG (which I believe currently uses >data: URIs) is one possible consumer of this. The example is very helpful. I suggest that similar examples be added to the respective specs. There is a huge difference between a spec that only talks about information items, and a spec that also contains an example to help the reader get a start. Also, I think it is very important to distinguish binary data from actual character data. One concern I have is that users of base64 in general or of this specific mechanism might misuse it to encode character data in a binary form, which would loose encoding identification which is done very well for XML. Can you please try to change the wording with this in mind? Please tell me if you want this checked. Regards, Martin. >A simplistic example might be; > >---8<--- >MIME-Version: 1.0 >Content-Type: Multipart/Related; boundary=MIME_boundary; >type=application/soap_mtom+xml; > start="<envelope01@example.org>" > >--MIME_boundary >Content-Type: application/soap_mtom+xml >Content-Transfer-Encoding: 8bit >Content-ID: <envelope01@example.org> > ><?xml version='1.0' ?> ><SOAP-ENV:Envelope xmlns:SOAP-ENV="..."> ><SOAP-ENV:Body> > <!--- xml content here --> > <Image type="image/jpeg"><Include xmlns="..." > href="cid:binary01@example.org"/></Image> > <!--- xml content here --> ></SOAP-ENV:Body> ></SOAP-ENV:Envelope> > >--MIME_boundary >Content-Type: image/jpeg >Content-Transfer-Encoding: binary >Content-ID: <binary01@example.org> > >[binary image] >--MIME_boundary-- >---8<--- > >Which could be transformed to this XML - > >---8<--- ><?xml version='1.0' ?> ><SOAP-ENV:Envelope xmlns:SOAP-ENV="..."> ><SOAP-ENV:Body> > <!--- xml content here --> > <Image type="image/jpeg">[base64-encoded image]</Image> > <!--- xml content here --> ></SOAP-ENV:Body> ></SOAP-ENV:Envelope> >---8<--- > >Is that helpful? > >Cheers & thanks, > >-- >Mark Nottingham Principal Technologist >Office of the CTO BEA Systems
Received on Thursday, 4 December 2003 14:28:33 UTC