Subject: RE: Private extension support (was Re: Q: Put request should return Atom entry?

From: "David Orchard" <[email-masked]>
Date: Mon, 19 Jul 2004 09:49:49 -0700

I wrote up some thoughts a while ago on applying some "standard" format extensibility rules to protocols

http://www.pacificspirit.com/blog/2004/06/14/protocol_extensibility_and_versioning

Seems like a reasonable question to ask, but it's harder to figure out what to do...

cheers,
Dave

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Mark Baker
> Sent: Sunday, July 18, 2004 9:50 PM
> To: Paul Hoffman / IMC
> Cc: Atom Syntax
> Subject: Private extension support (was Re: Q: Put request 
> should return
> Atom entry?
> 
> 
> 
> On Fri, Jul 16, 2004 at 08:27:40PM -0700, Paul Hoffman / IMC wrote:
> > Not quite. Because "servers MAY include", clients "MUST NOT 
> expect". 
> > This is a direct interoperability interpretation. If I'm creating a 
> > client that expects additional info, it will not interoperate with 
> > some conformant servers.
> 
> Mostly, but there are different forms of interoperatation.  By using
> "SHOULD NOT", I meant to support the case where private (but declared)
> extensions between clients and servers were used, which provides a
> degraded form of interop where agents not party to the extension can
> at least determine that they don't understand the message and fail
> gracefully.  For example, imagine an extension called
> "ReturnBodyOnPut" which a client declares as mandatory in the PUT
> message.
> 
> Discussion to date concerning Atom extensibility has 
> suggested the need
> for "must understand" support in the data format.  What I'm talking
> about is doing the same thing for the protocol, at least where the
> protocol supports it (e.g. SOAP).
> 
> The bigger question though, is whether or not the group is 
> interested in
> supporting private extensions.
> 
> Mark.
> -- 
> Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
> 
>   Seeking work on large scale application/data integration projects
>   and/or the enabling infrastructure for same.
> 
>

---

From: Mark Baker <[email-masked]>
Date: Mon, 19 Jul 2004 22:30:58 -0400

> http://www.pacificspirit.com/blog/2004/06/14/protocol_extensibility_and_versioning

Right-o.

> Seems like a reasonable question to ask, but it's harder to figure out what to do...

As I see it, we have three options, at least to begin with;

1. support (RESTful) SOAP
2. support RFC 2774
3. forget about it

With both #1 and #2, my plan is that vanilla HTTP would be used by
agents not implementing an incompatible extension.  For agents that do
support such an extension, we'd recommend that the extension be defined
using whichever one of those options we decide upon.  Where it gets
tricky is that we'd also need to define behaviour for agents that choose
not to support either option (since to support one is a significant
burden with no immediate payback) so that their behaviour is
consistent with that of an agent which does support it, but no
extensions.  For example, if we opted to use SOAP, then an Atom server
choosing not to support it would still need to be able to respond with a
SOAP mustUnderstand fault to all incoming SOAP requests (as we're
assuming that SOAP is only used when mustUnderstand is used, though
there's some wiggle room there we can play with).

FWIW, I'd personally like to see SOAP supported since extensibility is
what it's best at, and, unlike RFC 2774, actually has a deployed SDK or
two. 8-)

I'd be happy to spend the time writing a Pace on this - I just wanted to
get a feel from folks about whether that would be a waste of my time or
not.  Obviously I'd be looking directly to you, Dave, for support and
input because I believe you appreciate the importance and complexity of
this space.

Mark.

---

From: Joe Gregorio <[email-masked]>
Date: Mon, 19 Jul 2004 22:52:28 -0400

> 1. support (RESTful) SOAP

This did raise one question in my mind, right now the entries
used in the Publishing Protocol will contain a version of the 
Atom format. Does the Publishing Protocol needs its own 
version number on top of that?

I'll also note that an Introspection file [1] would be a good
place to enumerate versions and extensions.

[1]  http://intertwingly.net/wiki/pie/PaceIntrospection

    Thanks,
    -joe

-- 
Joe Gregorio        http://bitworking.org

---

From: Mark Baker <[email-masked]>
Date: Tue, 20 Jul 2004 07:58:23 -0400

> version number on top of that?

I hope and expect that it won't.

Mark.