Blast from the past: USENET Transport Binding for SOAP 1.1

[Nostra2004 at SAFe-mail.net]

USENET Transport Binding for SOAP 1.1 
10 February 2002 
Authors (alphabetically): 
Sister Tornado 

Copyright) 2002 Sister Tornado. Reproduce with credit at will. 


-------------------------------------------------------------------------------- 

Abstract 
SOAP [1] is a lightweight protocol for exchange of information in a decentralized, distributed environment, using XML. This document details transporting SOAP messages over the USENET. [2] 

Status 
This is a draft. 

Table of Contents 
1. Introduction 
1.1 Notational Conventions 
2. Use Of USENET Message body 
2.1 Encoding 
3. Identifying USENET transports in WSDL 
4. Request / Response semantics 
5. Examples 
6. Security Considerations 
7. References 

1. Introduction 
By binding SOAP to USENET, we can take advantage of USENET's store and forward messaging to provide an asynchronous, broadcast, one way transport for SOAP. Two one way messages can be correlated to provide request / response semantics (this closely follows the SOAP model). This allows SOAP to be used in a number of scenarios where HTTP is not suitable (partially connected nodes, one way notifications etc.) 

The author wishes to acknowledge that the shameless cribbing of much of the text from "SMTP Transport Binding for SOAP 1.1 
" [0]. 


1.1 Notational Conventions 
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [3]. 



2. Use of USENET Standard 

2.1 Use of USENET Message Headers 
The USENET Message standard requires the use of a Subject field. This field SHOULD be used to identify the service being called. 

For example: 

Subject: SoapRobot 

2.2 Use of USENET Message body 
SOAP payloads in USENET MUST be packaged into the body of the USENET message. 
2.3 Encoding 
A content transfer encoding of base64 is RECOMMENDED. A content transfer encoding of Quoted-Printable MAY be used if the SOAP payload meets the requirements of RFC-1036 [2]. 


3. Identifying USENET transports in WSDL 
The URI http://schemas.xmlsoap.com/soap/usenet/ SHOULD be used to identify USENET transports compliant with this specification in the transport attribute of the soap:binding element of a WSDL [4] document (see section 3.3 of the WSDL spec.) 

The address of the SOAP service in the soap:address element of a WSDL document SHOULD be the name or handle of the intended recipient and a comma-delimitedlist of newsgroups where a request may be posted. For example: 

<soap:address location="DarkNet at example.alt.soap.messages.trendy,example.alt.soap.messages.fake"> 

4. Request / Response semantics 
SOAP applications requiring request / response semantics will need to perform some sort of message correlation. This SHOULD be achieved via the standard Message-Id and Followup-To USENET headers [2]. The request will include a Message-Id header, and the associated response should include a Followup-To header that contains the Message-Id of the request, and a new Message-Id header. 

The responder SHOULD also reflect the incoming subject header into the response, prefixing it with "Re: ". 

5. Example 
A request destined for SoapRobot at example.soap.messages