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

 


Help: OASIS Mailing Lists Help | MarkMail Help

openc2-actuator message

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


Subject: SLPF: Do we need more response codes?


Actuator Profile SC, 

I am attempting to resolve comments regarding 'Response Codes' (Section 2.2.1 of the SLPF)   

In the original prose, I used the response codes from the language specification, then added options in the 'status text' to accommodate different scenarios.  

The comment I received was (paraphrased) 'status text is ignored in M2M.  If you need status sub codes, either define additional status codes or capture in the results field'.    The current SLPF has five status codes (102, 200, 400, 500 and 501) that were subdivided.  

This comment brings up two questions:  

QUESTION ONE: 
Do we need additional precision on the response codes or are the five status codes sufficient?  

QUESTION TWO:  If additional precision is needed, do we utilize the 'results' field or do we define additional codes?  

For example, currently we have an error code of 501 'not implemented', 

Do we use the results field?
	501: not implemented: Target not supported | Option not supported | Command not supported | other Do we define additional status codes?  
	
Or do we define additional codes?  
	501: not implemented
	521: Target not supported
	522: Option not supported
	...

This is my opinion:  I think we should have the one status code (501 not implemented) and OPTIONALLY put the different errors in the results field.  
My logic or lack thereof:  If a command fails and it is known why, then the orchestrator may be able to adjust the next commands.  This would be especially important in the case where the orchestrator 'knows' that a profile is supported but does not have the full schema, therefore does not know all of the options supported.  We do not necessarily want to require ALL actuators to support a wide range of response codes (that may never be applicable) or require the actuator to support sophisticated results fields, thus make populating the results field optional.  

Look at the modification I made in section 2.2.1 of the SLPF.   Would like your insights.  

VR

Joe Brule 




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