WSRP Description and Transport Issues SC Andre Kramer, Citrix Systems Inc. 8 th WSRP F2F, Gluecode Software, LA 1 st to 4 th March, 2004 Andre Kramer, Citrix Systems Inc. 8 th WSRP F2F, Gluecode Software, LA 1 st to 4 th March, 2004

Our 1.1 topic: Binary Attachments Per-last F2F: - Citrix DIME support documented - “SOAP Message Transmission Optimization Mechanism” W3C Working Draft 21 July 2003 Since last F2F: - Proposal written up to use SwA for out-of-band markupBinary & uploadData - Performance advantages demonstrated - WS-I.org Basic Profile 1.1 expected to add attachments, scheduled for mid-year “Attachments Profile Version 1.0” WS-I.org Working Group draft, 2003/12/ new W3C XML Protocol WG Drafts (9 th Feb 2004) Per-last F2F: - Citrix DIME support documented - “SOAP Message Transmission Optimization Mechanism” W3C Working Draft 21 July 2003 Since last F2F: - Proposal written up to use SwA for out-of-band markupBinary & uploadData - Performance advantages demonstrated - WS-I.org Basic Profile 1.1 expected to add attachments, scheduled for mid-year “Attachments Profile Version 1.0” WS-I.org Working Group draft, 2003/12/ new W3C XML Protocol WG Drafts (9 th Feb 2004)

W3C XMLP Drafts “XML-binary Optimized Packaging” W3C Working Draft 09 Feb 2004 – XOP (XML-binary Optimized Packaging) – For base64Binary Data only :-( – But a quite simple solution “SOAP Message Transmission Optimization Mechanism”, W3C Working Draft 09 Feb 2004 – Optimize the transmission and the wire format of SOAP – Uses XOP & Data Model (type info to select binary data) – Hop by hop but talks about intermediaries (nodes may optimize pass through) – Aims to supersede SOAP 1.2 Attachment Feature – Optimized MIME multipart serialization - how to serialize Soap envelope using XOP format & MIME multipart/related. – HTTP transmission optimization feature - for http binding “XML-binary Optimized Packaging” W3C Working Draft 09 Feb 2004 – XOP (XML-binary Optimized Packaging) – For base64Binary Data only :-( – But a quite simple solution “SOAP Message Transmission Optimization Mechanism”, W3C Working Draft 09 Feb 2004 – Optimize the transmission and the wire format of SOAP – Uses XOP & Data Model (type info to select binary data) – Hop by hop but talks about intermediaries (nodes may optimize pass through) – Aims to supersede SOAP 1.2 Attachment Feature – Optimized MIME multipart serialization - how to serialize Soap envelope using XOP format & MIME multipart/related. – HTTP transmission optimization feature - for http binding

XOP More efficient means of serializing XML Query 1.0 and XPath 2.0 Data Model – Need schema / type info to identify serialization candidates. Hence use of Data Model. – base64Binary data only XOP packages: – Placing serialization into extensible packaging format such as MIME multipart/related – Replacing seralization with a special element ( xop:Include ) that links to the packaged data using URIs – Spec sections: – Format of XOP packages – XOP Data Model – Processing Model (seems not very optimal to me :-( – Security (TBD) More efficient means of serializing XML Query 1.0 and XPath 2.0 Data Model – Need schema / type info to identify serialization candidates. Hence use of Data Model. – base64Binary data only XOP packages: – Placing serialization into extensible packaging format such as MIME multipart/related – Replacing seralization with a special element ( xop:Include ) that links to the packaged data using URIs – Spec sections: – Format of XOP packages – XOP Data Model – Processing Model (seems not very optimal to me :-( – Security (TBD)

XOP

XOP Example <soap:Envelope xmlns:soap=' xmlns:xop=' xmlns:xop-mime=' /aWKKapGGyQ= Faa7vROi2VQ=

MIME-Version: 1.0 Content-Type: Multipart/Related;boundary=MIME_boundary; type=text/xml;start=" " Content-Description: An XML document with my picture and signature in it --MIME_boundary Content-Type: text/xml; charset=UTF-8 Content-Transfer-Encoding: 8bit Content-ID: <soap:Envelope xmlns:soap=' xmlns:xop=' xmlns:xop-mime=' --MIME_boundary Content-Type: image/png Content-Transfer-Encoding: binary Content-ID: // binary octets for png --MIME_boundary Content-Type: application/pkcs7-signature Content-Transfer-Encoding: binary Content-ID: // binary octets for signature --MIME_boundary--

XOP and WSRP XOP currently only for base64Binary Markup strings require XML encoding or wrapping in CDATA sections Overhead of passing through XML parser Could convert: string bytes base64binary bytes string Consumer URL rewriting is an issue Problem of charset conversions Signed markup may be a 2.0 issue XOP currently only for base64Binary Markup strings require XML encoding or wrapping in CDATA sections Overhead of passing through XML parser Could convert: string bytes base64binary bytes string Consumer URL rewriting is an issue Problem of charset conversions Signed markup may be a 2.0 issue

What to binary encode in WSRP? MarkupContext.markupBinary (H) MarkupContext.markupString (H) UploadContext.uploadData (H) Property.value (H) ResourceList (M) RegistrationState.registrationState (M) RuntimeContext.templates (M) PortletContext.portletState (M) UserContext.userProfile (M) ModelType (L) ClientData.extensions? (L) UserContext.extensions? (L) fault.details? (L) …

Strawman for XOP Minimal proposal: – Use markupString for small fragments (UTF-8) – Else use markupBinary and UploadContext.uploadData (these are already base64binary ) – Add a Property.value base64binary element - so that XOP can pull out property get/set data – Need a standard way to name the new binding (An aside: SOAP1.2 binding will also need to be named) More elaborate MTO scheme possible, e.g.: – Could use X Pointer to reference any element that should be optimized – Use WSRP schema to encode/decode selected elements – Could be added as additional bindings Minimal proposal: – Use markupString for small fragments (UTF-8) – Else use markupBinary and UploadContext.uploadData (these are already base64binary ) – Add a Property.value base64binary element - so that XOP can pull out property get/set data – Need a standard way to name the new binding (An aside: SOAP1.2 binding will also need to be named) More elaborate MTO scheme possible, e.g.: – Could use X Pointer to reference any element that should be optimized – Use WSRP schema to encode/decode selected elements – Could be added as additional bindings

WS-I.org Basic Profile 1.1 draft Splits out SOAP binding from Basic Profile 1.0 Draft adds Attachments “1.0” Profile – SOAP Messages with Attachments (SwA) – MIME multipart/related structure for packaging – Root part MUST be soap:Envelope – Supports ref:swaRef – from WSDL 1.1 Section 5 – Good for markup but not for our uploadData or properties – Could add new unparsedUploadData message part for attachment – Or use our out-of-band approach? What to name this binding? – WSRP_v1_1_Markup_Binding_SwA ? – Does it need to be in a separate service.wsdl? Splits out SOAP binding from Basic Profile 1.0 Draft adds Attachments “1.0” Profile – SOAP Messages with Attachments (SwA) – MIME multipart/related structure for packaging – Root part MUST be soap:Envelope – Supports ref:swaRef – from WSDL 1.1 Section 5 – Good for markup but not for our uploadData or properties – Could add new unparsedUploadData message part for attachment – Or use our out-of-band approach? What to name this binding? – WSRP_v1_1_Markup_Binding_SwA ? – Does it need to be in a separate service.wsdl?

How to proceed? Encourage XOP to handle other data types? XML-encoded Strings use case Live with minimal base64Binary proposal? Allow non-interoperable aggressive serialization optimization schemes? Wait for WS-I.org Basic Profile 1.1? Encourage XOP to handle other data types? XML-encoded Strings use case Live with minimal base64Binary proposal? Allow non-interoperable aggressive serialization optimization schemes? Wait for WS-I.org Basic Profile 1.1?