OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

coel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] (COEL-122) BAP: Ensure that a caller knows what to do with an Atom if upload fails.


     [ https://issues.oasis-open.org/browse/COEL-122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Bruton updated COEL-122:
-----------------------------

    Description: 
When an atom source sends an atom to a data engine, there are loosely three possibilities:

1. Success: The DE has received the atom, accepted it and will take responsibility for it.
2. Sender-Failure: The DE has received the Atom but cannot accept it (it is badly formed, missing mandatory fields etc). 
3. Receiver-Failure: The DE has not received the Atom or has received it but cannot handle it at the moment or the caller used the wrong endpoint ( capacity, network failure etc).

In each of these cases, the sender knows what to do:
1 & 2: Forget about the Atom, don't send again. 
3: Try to send the Atom again.

The BAP specifies return codes from Atom Post, but in Scheme 1 there are only two.

202 - is case 1 above
500 - sender cannot distinguish cases 2 or 3.

In scheme 2 there is a bit more detail, but there are only five codes stipulated and it is not explicit what the mapping would be:

202 - case 1
400 - case 2
404 - case 3 (wrong endpoint?)
500 - case 3 (internal error)

Suggestion is that we make these three cases explicit and be a bit less prescriptive on the return codes:

2xx - success, case 1 (some DE return 201, some 200)
5xx - failure case 3. Most likely a DE internal failure, sender can try again.
4xx - Mostly these are case 2 (badly formed) but there are also case-3 (unauthorised or forbidden) where the client can try again, albeit with correct credentials:
          I would propose something simple:
          400 - 1 or more atoms in the submission is badly formed and can never be accepted. If it is a batch, client can resubmit 1-by-1, if an individual atom, perhaps try once more in case transmission was garbled and then discard atom.

          The list below is not complete and needs some thought but some specific cases are obvious
          401/403: Client needs authorisation (does not say if the Atom is OK or not)
          404: Endpoint not found, Client probably needs to try the information request, Does not say if Atom is OK or not
          400: bad request, malformed atom, client should not try again (unless it is a batch and can submit 1-by-1)
          413: Payload too big - if a batch, try 1-by-1


Question is what about an Atom that is syntactically correct but where the consumer or device ID is not known? The DE can 'accept' it (202) for association later, or reject it (case 3) for sending later. Some discussion needed here.....




  was:
When an atom source sends an atom to a data engine, there are loosely three possibilities:

1. Success: The DE has received the atom, accepted it and will take responsibility for it.
2. Sender-Failure: The DE has received the Atom but cannot accept it (it is badly formed, missing mandatory fields etc). 
3. Receiver-Failure: The DE has not received the Atom or has received it but cannot handle it at the moment or the caller used the wrong endpoint ( capacity, network failure etc).

In each of these cases, the sender knows what to do:
1 & 2: Forget about the Atom, don't send again. 
3: Try to send the Atom again.

The BAP specifies return codes from Atom Post, but in Scheme 1 there are only two.

202 - is case 1 above
500 - sender cannot distinguish cases 2 or 3.

In scheme 2 there is a bit more detail, but there are only five codes stipulated and it is not explicit what the mapping would be:

202 - case 1
400 - case 2
404 - case 3 (wrong endpoint?)
500 - case 3 (internal error)

Suggestion is that we make these three cases explicit and be a bit less prescriptive on the return codes:

2xx - success, case 1 (some DE return 201, some 200)
5xx - failure case 3. Most likely a DE internal failure, sender can try again.
400 - syntax error in atom, no point in trying again.

Question is what about an Atom that is syntactically correct but where the consumer or device ID is not known? The DE can 'accept' it (202) for association later, or reject it (case 3) for sending later. Some discussion needed here.....





> BAP: Ensure that a caller knows what to do with an Atom if upload fails.
> ------------------------------------------------------------------------
>
>                 Key: COEL-122
>                 URL: https://issues.oasis-open.org/browse/COEL-122
>             Project: OASIS Classification of Everyday Living (COEL) TC
>          Issue Type: Improvement
>            Reporter: Paul Bruton
>
> When an atom source sends an atom to a data engine, there are loosely three possibilities:
> 1. Success: The DE has received the atom, accepted it and will take responsibility for it.
> 2. Sender-Failure: The DE has received the Atom but cannot accept it (it is badly formed, missing mandatory fields etc). 
> 3. Receiver-Failure: The DE has not received the Atom or has received it but cannot handle it at the moment or the caller used the wrong endpoint ( capacity, network failure etc).
> In each of these cases, the sender knows what to do:
> 1 & 2: Forget about the Atom, don't send again. 
> 3: Try to send the Atom again.
> The BAP specifies return codes from Atom Post, but in Scheme 1 there are only two.
> 202 - is case 1 above
> 500 - sender cannot distinguish cases 2 or 3.
> In scheme 2 there is a bit more detail, but there are only five codes stipulated and it is not explicit what the mapping would be:
> 202 - case 1
> 400 - case 2
> 404 - case 3 (wrong endpoint?)
> 500 - case 3 (internal error)
> Suggestion is that we make these three cases explicit and be a bit less prescriptive on the return codes:
> 2xx - success, case 1 (some DE return 201, some 200)
> 5xx - failure case 3. Most likely a DE internal failure, sender can try again.
> 4xx - Mostly these are case 2 (badly formed) but there are also case-3 (unauthorised or forbidden) where the client can try again, albeit with correct credentials:
>           I would propose something simple:
>           400 - 1 or more atoms in the submission is badly formed and can never be accepted. If it is a batch, client can resubmit 1-by-1, if an individual atom, perhaps try once more in case transmission was garbled and then discard atom.
>           The list below is not complete and needs some thought but some specific cases are obvious
>           401/403: Client needs authorisation (does not say if the Atom is OK or not)
>           404: Endpoint not found, Client probably needs to try the information request, Does not say if Atom is OK or not
>           400: bad request, malformed atom, client should not try again (unless it is a batch and can submit 1-by-1)
>           413: Payload too big - if a batch, try 1-by-1
> Question is what about an Atom that is syntactically correct but where the consumer or device ID is not known? The DE can 'accept' it (202) for association later, or reject it (case 3) for sending later. Some discussion needed here.....



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]