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.
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.....




  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 (201) 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.
> 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.....



--
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]