1 / 1

SPPP “Transport” Specification draft-cartwright-drinks-sppp-over-soap-01

This document presents a concise update on the SPPP Transport Specification draft, focusing on recent discussions and comments received from IETF 77. The updates primarily address the ongoing considerations for Use Cases and Protocols. Key points include the preference for a thin SOAP/WSDL wrapper over a thick WSDL, the adoption of HTTP Digest as the authentication method, and the decision to retain the current approach for defining XML. The design team's emphasis remains on beneficial practices, avoiding unnecessary protocol transport agnosticism while enhancing dependency management in messaging.

nami
Télécharger la présentation

SPPP “Transport” Specification draft-cartwright-drinks-sppp-over-soap-01

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SPPP “Transport” Specification • draft-cartwright-drinks-sppp-over-soap-01 • Status Update • Really just a couple updates, as Use Cases and Protocol were focus of this cycle. • Adopted as a WG Document • Discussed and considered four notable comments from IETF 77, also soliciting feedback on the mailing list • Use of thin SOAP/WSDL wrapper as the messaging envelope, rather than thick WSDL, lessens the value of SOAP. • Use of HTTP Digest as the authentication protocol rather than the WS security service is not really standards compliant. • Do not make the protocol transport agnostic, it is not necessary to do so. • Do not use XSD, just define XML via documentation and examples. • Decided to stick with the current approach as it is still the preferred approach of the design team for the original reasons. • Helps make the protocol transport/envelope agnostic. • HTTP Digest is a standard and is in keeping with other protocols. • Transport/Protocol agnostic is “easy” and avoids unnecessary coupling. • Using XSDs to define XML data structures is good practice, widely used, and highly beneficial.

More Related