Re: Accept-Post submission and call for implementation info

Hi,

On Wed, Sep 4, 2013 at 8:36 PM, Steve Speicher <sspeiche@gmail.com> wrote:

> Hi Andrei,
>
> On Wed, Sep 4, 2013 at 2:13 PM, Andrei Sambra <andrei.sambra@gmail.com>wrote:
>
>>  Hi all,
>>
>> Here is the description for my implementation of Accept-Post header:
>>
>> - The organization responsible for the implementation, if any.
>> No particular organization. The work done is part of project RWW.I/O (
>> https://rww.io/).
>>
>> - The implementation's name and/or a link to a web page describing the
>> implementation.
>> RWW.I/O - personal linked data storage.
>>
>> - A brief general description.
>> A minimal support for LDP is now included in RWW.I/O, which is a personal
>> linked data storage space, following the structure of a unix file system.
>> Currently, only LDPCs are supported, since the LDPRs are always files or
>> directories that are being managed through RESTful operations. RWW.I/O
>> encourages the use of .meta files to semantically describe non-LD resources
>> (e.g. images, html, js, css, etc.), and the use of .acl files for access
>> control rules using the WAC vocabulary. Both .meta and .acl should be used
>> per file (i.e. photo.jpg will have a .meta.photo.jpg and a .acl.photo.jpg).
>>
>> - The implementation's level of maturity: research, prototype, alpha,
>> beta, production, widely used, etc.
>> Beta until more features from LDP spec are included (if necessary).
>>
>> - Coverage: which parts of the protocol specification are implemented and
>> which versions of the Internet-Draft were implemented.
>> LDPCs on the server side, pagination and Accept-Post header.
>>  You can test LDPC support like this: curl -H "Accept: text/turtle"
>> https://deiu.rww.io/public/?p=1
>> You can test Accept-Post header like this: curl -v -X OPTIONS -H "Accept:
>> text/turtle" https://deiu.rww.io/public/
>>
>> - Licensing: the terms under which the implementation can be used. For
>> example: proprietary, royalty licensing, freely distributable with
>> acknowledgement (BSD style), freely distributable with requirement to
>> redistribute source (General Public License (GPL) style), and other
>> (specify).
>> MIT license. Source code is available on GitHub at
>> https://github.com/deiu/rww.io
>>
>> - Implementation experience: any useful information the implementers want
>> to share with the community.
>> Implementing current LDP features in RWW.I/O was trivial. I've also
>> decided to add the Accept-Post header to HEAD replies, as it helps to
>> reduce the number of requests for a client trying to discover more
>> information about the server.
>>
>
> This is good to see.  I assume this then means it is available on GET
> response too.  Do you supply this on a POST response, especially when it is
> unsupported media type (415)?
>

Good point, I will add it right away for both POST and PUT.


>
> I tested this but I received a 406 instead of 415 (and I didn't get the
> Accept-Post header but would be good to get it in this case).  Which makes
> me think which is the right choice.  Now that we have an accept type
> header, one could see that 406 might be the right status code
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.7
>

>From what I could tell after reading the spec, there is no mention of a
specific HTTP code that should be returned after a failed POST. However,
HTTP 415 Unsupported Media Type does seem to be more appropriate in this
case.

Andrei


>
> $curl -v -X POST -H "Content-type: text/steve" https://deiu.rww.io/public/
>
> - Steve Speicher
>
>
>>
>> Best,
>> Andrei
>>
>>
>>
>> On Tue, Sep 3, 2013 at 10:22 PM, Wilde, Erik <Erik.Wilde@emc.com> wrote:
>>
>>> thanks a lot, steve! cheers, dret.
>>>
>>> On Sep 3, 2013, at 12:36, "Steve Speicher" <sspeiche@gmail.com> wrote:
>>>
>>> Hi Erik,
>>>
>>> Here is the information about the implementation I have done and for
>>> inclusion in
>>> http://tools.ietf.org/html/draft-wilde-accept-post-00#section-6
>>>
>>> - The organization responsible for the implementation, if any.
>>> IBM developed and contributed to the Eclipse Lyo project, see
>>> http://eclipse.org/lyo
>>>
>>> - The implementation's name and/or a link to a web page describing the
>>> implementation.
>>> Eclipse Lyo "LDP reference implementation"
>>> http://wiki.eclipse.org/Lyo/BuildLDPSample
>>>
>>> - A brief general description.
>>> A very simple reference implementation for W3C Linked Data Platform
>>> (LDP) using some base Java technologies such as JAX-RS 2.0 and Apache Jena.
>>>   The goals of this reference implementation is to experiment with
>>> validating the concepts in the specification and understanding what a SDK
>>> might look like to build LDP-compliant servers. Additional goal is to
>>> validate the approach for usage in OSLC4J SDK for building OSLC (
>>> http://open-services.net) clients and servers.
>>>
>>> - The implementation's level of maturity: research, prototype, alpha,
>>> beta, production, widely used, etc.
>>> Early prototype/alpha.
>>>
>>> - Coverage: which parts of the protocol specification are implemented
>>> and which versions of the Internet-Draft were implemented.
>>> All were covered for server requirements.
>>>
>>> - Licensing: the terms under which the implementation can be used. For
>>> example: proprietary, royalty licensing, freely distributable with
>>> acknowledgement (BSD style), freely distributable with requirement to
>>> redistribute source (General Public License (GPL) style), and other
>>> (specify).
>>> freely distributable (EPL and EDL)
>>> The Eclipse Public License (EPL) is available at
>>> http://www.eclipse.org/legal/epl-v10.html and the Eclipse Distribution
>>> License (EDL) is available at
>>> http://www.eclipse.org/org/documents/edl-v10.php.
>>>
>>> - Implementation experience: any useful information the implementers
>>> want to share with the community.
>>> Experience is only from the server perspective of generating the HTTP
>>> response header.  It was very trivial using JAX-RS 2.0 mechanism using a
>>> ContainerResponseFilter on all responses.  There are more details about
>>> this approach at
>>> http://stevespeicher.blogspot.com/2013/08/supporting-accept-post-in-jax-rs.html
>>>
>>> Let me know if there is anything else you'd need.  I expect to have a
>>> few more mature implementations using this shortly as well.
>>>
>>> - Steve Speicher
>>>
>>>
>>> On Mon, Jul 29, 2013 at 5:31 AM, Wilde, Erik <Erik.Wilde@emc.com> wrote:
>>>
>>>> hello.
>>>>
>>>> the Accept-Post proposal now has been submitted as a draft
>>>> http://tools.ietf.org/html/draft-wilde-accept-post-00 , and it has been
>>>> announced on the apps-discuss list
>>>> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10109.html.
>>>>
>>>> our goal now is to push this along as fast as we can. IETF processes are
>>>> mostly driven by community feedback, so any support for this draft
>>>> voiced
>>>> on apps-discuss will help. also,
>>>> http://tools.ietf.org/html/draft-wilde-accept-post-00#section-6 is
>>>> empty,
>>>> and it would be great to add implementations to it. please take a look
>>>> at
>>>> http://tools.ietf.org/html/rfc6982#section-2 and submit your
>>>> implementation information, if you have implemented Accept-Post. either
>>>> send it to me directly, or if you feel like it, fork
>>>> https://github.com/dret/I-D/tree/master/accept-post and submit your
>>>> info
>>>> as a pull request through github.
>>>>
>>>> thanks a lot and cheers,
>>>>
>>>> dret.
>>>>
>>>>
>>>>
>>>
>>
>