[Form Submission API] Issues....

[Jørn Klungsøyr]

Hi,

There are a number of issues here that are not clear, and which is why I
voted -1.

____________
Under Channel:
-------------------
* OpenRosa servers must provide a globally accessible HTTP URL capable of
accepting HTTP POST's from arbitrary origins.
? This is a deployment specific issue - does not belong in a standard.

* The HTTP URL should not redirect to another URL. Clients are not required
to correctly follow HTTP redirects on a POST attempt.
? Why would we set this kind of limitation? It also seems to contradict with
this sentence in Extended Transmission Considerations: "In this way, the
server can change the scheme from http: to https: or update the submission
page URL without a wasted redirect during the actual submission process."

______________
Under Content:
----------------------
* Error responses SHOULD include this header. For some hosting environments,
such as Google AppEngine, it may not be possible to include this header
under all failure conditions (e.g., overly-large requests).
? A response not containing this should rather be treated as an indication
of failure by the client, and if a response MUST include the header, then
the client can understand what the missing header means. I assume that any
server in certain cases could send a non-valid response - but still be
OpenROSA compliant - and the client then knows that the response is invalid.

* it is recommended that the client split the POST into multiple individual
POST requests, each containing the form's xml submission and one or more
additional parts such that each partial POST request is no greater than
maxSize; if a single additional part is greater than maxSize, the POST
should contain the form's xml submission and that single additional part.
? Why is it needed to submit the xml on each repeat?

_______________
Under Correctness:
------------------------
For instance, if a server identifies early in a form submission that a
duplicate UUID is used, the server should not close the channel immediately,
but rather accept the full submission and then respond accordingly.

_________________________
Under Server Response Format
* If the target server is RESTful, it may return an HTTP URL where the form
can be found in the HTTP Location response header.
Could this not be standardized - so that non RESTful servers also can give
an indication of identification of the submission? What if the OpenROSA
response xml was standardized a bit more?
<message> REQUIRED
<URL> Optional
<ID> Optional

____________________________________________________________________________
Jorn Klungsoyr
openXdata - Centre for International Health, University of Bergen, Norway
www.openxdata.org / www.cih.uib.no / www.openrosa.org / www.open-mobile.org
Mobile: +4791365731, Skype/GoogleTalk: jornklung Alternative email:
jorn.kl...@gmail.com
Post: Postboks 7800, 5020 Bergen, Visit: Årstadveien 21, 5th Floor, Bergen
------¤¤¤¤------

[Clayton Sims]

Some explanations from the original writeup and skype chats inline:

On Thu, Dec 1, 2011 at 2:33 AM, Jørn Klungsøyr <jorn.klung...@gmail.com> wrote:

____________
Under Channel:
-------------------
* OpenRosa servers must provide a globally accessible HTTP URL capable of
accepting HTTP POST's from arbitrary origins.
? This is a deployment specific issue - does not belong in a standard.

The standards issue here is whether OpenRosa servers are expected to be capable of working with all devices from the WAN. I'm not 100% attached to the condition, but I think "Your server needs to be visible from the WAN" makes a good guarantee to groups who are looking to use arbitrary openrosa mobiles with arbitrary openrosa servers that they will be able to do so.

 

* The HTTP URL should not redirect to another URL. Clients are not required
to correctly follow HTTP redirects on a POST attempt.
? Why would we set this kind of limitation? It also seems to contradict with
this sentence in Extended Transmission Considerations: "In this way, the
server can change the scheme from http: to https: or update the submission
page URL without a wasted redirect during the actual submission process."

Hm, not 100% sure here. I think there were concerns that through various mobile networks HTTP redirects don't necessarily get processed correctly, so if servers rely on them we can't guarantee that the two sides can talk, but honestly I can't remember whether those turned out to be valid. 

Have people experienced issues with http redirects in the past on certain devices/frameworks/networks?

 

______________
Under Content:
----------------------
* Error responses SHOULD include this header. For some hosting environments,
such as Google AppEngine, it may not be possible to include this header
under all failure conditions (e.g., overly-large requests).
? A response not containing this should rather be treated as an indication
of failure by the client, and if a response MUST include the header, then
the client can understand what the missing header means. I assume that any
server in certain cases could send a non-valid response - but still be
OpenROSA compliant - and the client then knows that the response is invalid.

I'm not sure what the question is here. I think the language is just implying that the server should make an effort to return that header whenever possible, but that compliance won't be broken if the header isn't returned when failures occur.

 

* it is recommended that the client split the POST into multiple individual
POST requests, each containing the form's xml submission and one or more
additional parts such that each partial POST request is no greater than
maxSize; if a single additional part is greater than maxSize, the POST
should contain the form's xml submission and that single additional part.
? Why is it needed to submit the xml on each repeat?

 

Mitch and I had a long discussion about this in the past. I tend to assume that re-sending the xml is redundant, maybe he can chime in on why it's viewed as essential?

 

_______________
Under Correctness:
------------------------
For instance, if a server identifies early in a form submission that a
duplicate UUID is used, the server should not close the channel immediately,
but rather accept the full submission and then respond accordingly.

Was the question why this is in the spec? Cutting off the channel prematurely implies that the submission itself was unsuccessful. Posting duplicates isn't an unsuccessful post, it's an irrelevant one, so we shouldn't confuse the layers.

_________________________
Under Server Response Format
* If the target server is RESTful, it may return an HTTP URL where the form
can be found in the HTTP Location response header.
Could this not be standardized - so that non RESTful servers also can give
an indication of identification of the submission? What if the OpenROSA
response  xml was standardized a bit more?
<message>  REQUIRED
<URL> Optional
<ID> Optional

Individual servers can insert their own elements into the openrosa response IE:

<OpenRosaResponse xmlns="http://openrosa.org/http/response"> 

    <message>Form Received! You've submitted 5 forms today</message> 

    <ssr:SpecificServerResponse xmlns="http://myserver.org/responses">

        <ssr:url>myserver.org/implementation/fetcher</ssr:url>

        <ssr:id>234324234324</ssr:id>

    </ssr:SpecificServerResponse>

</OpenRosaResponse>

The REST location response is just to be in maximal conformance with the 201 response code for RESTful systems. I'm only pro adding url/id style updates if we think that all of the systems will have the ability to feed back forms from the server with a consistent api.

[Mitch S]

I'll respond on the chat...

--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com