Subject: [drinks] Session @ IETF 82

From: Alexander Mayrhofer <[email-masked]>
Date: Mon, 26 Sep 2011 09:04:03 +0200

All,

we have decided to request a 90 minute session @ IETF 82 in Taipei,
since the structural changes to the protocol / transport document to
accomodate the abstraction requirements will probably delay the
documents up to that meeting.

In case we finish earlier, we can still cancel the slot. 

Proposals for Agenda items (beyond the obvious discussion around the two
remaining working group documents) are appreciated.

thanks,

Alex

---

From: "Cartwright, Ken" <[email-masked]>
Date: Mon, 26 Sep 2011 15:48:14 -0400

Ok, but just for clarification I'd call this effort that we are now taking on one that will make the SPP more amenable to ReST _specifically_ (because ReST wants to control, to one extent or another, how to do object identity, and how to handle the verbs, and how to handle the response codes) rather than one to "accommodate the abstraction requirements".  Transports and envelopes do not typically attempt to define application specific constructs like that, but ReST attempts to.  The SPP protocol, as it stands today, can already be cleanly mapped onto TCP, HTTP, BEEP, RPCs, UDP, files, SOAP, async message oriented middleware, etc, because these are really just transport mechanisms and/or generic envelopes.  ReST is not a transport or an envelope.  ReST is more in the category of an architectural framework and approach, like CORBA, RMI, etc, because its edicts go well beyond specifying the transport and/or the envelope.  Needless to day, we never designed SPP so that it could fit within any set of architectural frameworks or approaches.  Rather, we designed it so that it could be mapped onto multiple transports and/or generic envelopes that can cleanly support XML as the request/response payload structure.  The work we are now taking on is not work that will make SPP amenable to any architectural framework/approach; we are modifying it in a way that will _also_ make it specifically adaptable to the ReST architectural framework/approach.

Ken

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Mayrhofer
Sent: Monday, September 26, 2011 3:04 AM
To: [email-masked]
Subject: [drinks] Session @ IETF 82

All,

thanks,

Alex

_______________________________________________
drinks mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/drinks

This e-mail message is for the sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Services.
Any unauthorised review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.