[oslc-core] Encoding of OSLC resources

[Steve K Speicher]

John,

I agree with your assessment.  The HTTP spec says that:

        "If an Accept-Encoding field is present in a request, and if the 
server cannot send a response which is acceptable according to the 
Accept-Encoding header, then the server SHOULD send an error response with 
the 406 (Not Acceptable) status code. "

So a compliant server can pick to ignore this and send back what it is 
optimized for OR it would be smart enough to honor this and 406 response 
code if not acceptable.  We could reiterate this best practices in OSLC 
specs if desired.   A client must tolerate these cases and be prepared to 
adopt the response or ignore it.

Thanks,
Steve Speicher | IBM Rational Software | (919) 254-0645

> From: John Arwe/Poughkeepsie/IBM at IBMUS
> To: Frank Budinsky <frankb at ca.ibm.com>, 
> Cc: oslc-core at open-services.net, Vivek Garg/Cupertino/IBM at IBMUS
> Date: 12/07/2011 01:49 PM
> Subject: Re: [oslc-core] Encoding of OSLC resources
> Sent by: oslc-core-bounces at open-services.net
> 
> So you're after the "...iron clad guarantee...". 
> If the client supports at least one of UTF-8 and UTF-16 and requests an 
> encoding that it understands, it has done all it can do within HTTP. 
> It sounds like the problem from your point of view is that no HTTP 
client 
> (OSLC or not) technically can force a server to answer in a particular 
> format/encoding (even if the server supports it), using only HTTP. 
That's a
> separate issue from the above.  OSLC could constrain origin servers' 
> behavior (for OSLC providers), but that either runs counter to the Open 
> World model (OSLC Primer) or only covers a proper subset of possible 
linked-
> to resources.  To be specific: a constraint on OSLC providers would not 
help
> when OSLC resources link to "not OSLC provided" resources; if that's 
still 
> sufficient for your use cases, then it is a constraint that Core could 
debate. 
> It appears that HTTP took the approach of tilting the incentives (social 

> solution via the network effect) toward supporting both UTF-8 and UTF-16 
for
> servers serving XML responses rather than requiring it as a matter of 
> compliance.  My best guess would be that was intentional to keep very 
loose 
> coupling.  I'd personally be hesitant to take a stronger stance in OSLC 
> unless there are known cases where important data is not available in 
UTF 8 
> or 16 *and* we expect that situation to persist indefinitely even in the 

> face of education about all the potential integrations that doing so is 
> giving up on *and* we think a change in stance by OSLC would cause those 

> parties to add UTF 8/16 support.  If the latter condition is not 
satisfied, 
> changing OSLC would not help in the end. 
> Best Regards, John
> 
> Voice US 845-435-9470  BluePages 
> Tivoli OSLC Lead - Show me the Scenario 
> 
> 
> 
> 
> From:        Frank Budinsky/Toronto/IBM at IBMCA 
> To:        John Arwe/Poughkeepsie/IBM at IBMUS 
> Cc:        oslc-core at open-services.net, Vivek Garg/Cupertino/IBM at IBMUS 
> Date:        11/30/2011 04:19 PM 
> Subject:        Re: [oslc-core] Encoding of OSLC resources 
> 
> 
> Hi John, 
> 
> Thanks for the speedy response. 
> 
> > If your question is "is there any particular encoding(s) that a client 

> must be able to understand in order to process any response from any 
producer" 
> 
> Yes, that's the question. If the answer to your second question were 
yes, 
> then that would be the way to solve this one, but since it's no, I think 

> we're stuck with the problem of how can a "complaint OSLC client" know 
that 
> it's capable of processing the resources from any "compliant OSLC 
server"? 
> Maybe, as you say, we should just accept the web as it is. 
> 
> Thanks, 
> Frank. _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net