Might use the existing HTTP Warn header for this kind of thing. While the primary current use is for cache "awareness", other uses are permitted. Extension codes allowed. HTTPbis is defining a registry for warn codes, but it is not visible at the IANA site yet.
To be clear: any proposal using this would have to make it clear (for compatibility reasons) that clients must be PESSimistic about it. If an update request returns an "Unrecognized content ignored" Warn header, then the client would have positive confirmation of the server's behavior; if not, the client is responsible for figuring it out (as is the case today). [1] http://tools.ietf.org/html/rfc2616#section-14.46 [2] http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-20#section-7.6 Best Regards, John Voice US 845-435-9470 BluePages Tivoli OSLC Lead - Show me the Scenario [email protected] wrote on 09/14/2012 01:56:23 PM: > From: Arthur Ryman <[email protected]> > To: James Conallen/Philadelphia/IBM@IBMUS > Cc: [email protected], Adam Neal <[email protected]>, > [email protected] > Date: 09/14/2012 01:58 PM > Subject: Re: [oslc-core] Unrecognized content > Sent by: [email protected] > > Jim, > > I think we may be stretching the analogy here. > > I am OK with you proposal: "I am ok if we just state that this scenario > can happen, and that the client is responsible for determining if the > update was successful (from its view) by GETing the representation > immediately after and checking the content and comparing the ETags." > > Pls draft some text and say where it should be included so we have a > concrete proposal on the table. > > Regards, > ___________________________________________________________________________ > > Arthur Ryman > > DE, Chief Architect, Reporting & > Portfolio Strategy and Management > IBM Software, Rational > > Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)
