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-12) Might need a look before you leap function for large atom downloads.


    [ https://issues.oasis-open.org/browse/COEL-12?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=61632#comment-61632 ] 

David Snelling commented on COEL-12:
------------------------------------

In earlier discussions this opertion was sighted as a Hish Risk operaton and should be subject extra care. For reverence Action Item 35 says:

Describe the 2FA callback approach to be used for high risk items in MMI. (see COEL-26) Note that the Operator can initiate a call to forget a consumer or reassign a device, but the Service Provider must provide the final go-ahead through a callback mechanism (e.g. email). The Operators call to the MMI does not block waiting for the Service Provider, it returns immediately to the caller, who cannot tell if it has been approved at this point. (Note that reassignDevice is not in the MMI yet - we should put in a placeholder?) Note that COEL-12 seems similar to this (look before you leap) but the email callback mechanism might be confusing, better to use a more standard RESTful approach of returning a URI which can be used by the caller to retrieve the data in batches.

In this case probably a URL from which large query results coupld be retrieved should be added to the spec. 

> Might need a look before you leap function for large atom downloads.
> --------------------------------------------------------------------
>
>                 Key: COEL-12
>                 URL: https://issues.oasis-open.org/browse/COEL-12
>             Project: OASIS Classification of Everyday Living (COEL) TC
>          Issue Type: New Feature
>            Reporter: David Snelling
>            Assignee: David Snelling
>            Priority: Minor
>
> The DE should potentially have an ‘offline’ approach (or double check) for ‘all atoms’ requests from Service Provider to Data Engine. This is to protect from too large a message and to improve the implementation of RPE. The later means this issue needs some discussion.



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