Hi Kevin,

CT1.2.3 is a Partial UPDATE test case.  The CTT/ITT is supposed to send a GET 
(step 1) to get a current representation of the Resource.  Then, the CTT/ITT is 
supposed to send a POST (step 4) to update one of the Properties.

I am not sure how the ITT has implemented this but you should see both a GET 
and a POST.

Mitch

-----Original Message-----
From: cftg at openconnectivity.org [mailto:[email protected]] On Behalf 
Of Joo-Chul Lee
Sent: Friday, April 22, 2016 12:57 AM
To: iotivity-dev at lists.iotivity.org; cftg at openconnectivity.org
Subject: [cftg] Question regarding ITT test case

Hello, folks

I'm currently testing our codes with "ITT (IoTivity Test Tool) 
(https://wiki.iotivity.org/conformance_test_tool)".
While I'm running ITT test case CT1_2_3, I face weird situation.

Below is test description of CT1_2_3::1
=========================================
     ...    |procedure |1. CTT sends a unicast RETRIEVE request message 
(i.e. CoAP GET) to the IUT to the first supported OIC Resource. |
     ...    |procedure |2. IUT receives the request message and sends a 
unicast response message to the CTT. |
     ...    |procedure |3. CTT creates a list of current values for each 
supported Property. |
     ...    |procedure |4. CTT sends a unicast CON UPDATE request 
message (i.e. CoAP POST) to the IUT with no OIC Resource Interface specified to 
the first writable supported Property (excluding common Properties rt, if, p, 
n, etc.) on the first supported OIC Resource. The Property value to be written 
must be valid (e.g. within the allowable range, valid enumeration value, etc.) 
and must be different than the current Property value. |
     ...    |procedure |5. IUT receives the request message and verifies 
that it is valid (i.e. Can the Property be updated? Does the OIC Resource 
Interface support UPDATE requests? Etc.) |
     ...    |procedure |6a. If the request message is valid, the IUT 
shall update the target OIC Resource Property as requested and send a 
successful UPDATE response message to CTT using the appropriate OIC Resource 
Interface. |
     ...    |procedure |6b. If the request is not valid, the IUT shall 
not update the target OIC Resource Property and shall send an appropriate error 
message to CTT.. |
     ...    |procedure |7. CTT receives the response message and caches 
it for later evaluation. |
     ...    |procedure |8. CTT sends a unicast CON RETRIEVE request 
message (i.e. CoAP GET) to the first supported OIC Resource of the IUT. |
     ...    |procedure |9. IUT receives the request message and sends a 
RETRIEVE response message to CTT. |
     ...    |procedure |10. CTT receives the response message and caches 
it for later evaluation. |
     ...    |procedure |11. Repeat steps 1 to 10 for all other writable 
Properties supported by the OIC Resource. |
     ...    |procedure |12. Repeat steps 1 to 11 for all other OIC 
Resources supported by the IUT. |
     ...    |post_condition |None |
     ...    |expected| Check 1. The IUT shall indicate support for CBOR 
and payload encoding shall use CBOR unless a different content type (i.e. JSON) 
has been negotiated (8.1 CRUDN Overview [CORE], 7.2.1.2 Resource interface 
property definition [CORE]). |
     ...    |expected| Check 3. The IUT shall send a response code of 
"2.04 Changed" (for CoAP) when the Property value has been successfully updated 
in Step 6a (8.1 CRUDN Overview [CORE], 12.2.1 Mapping of CRUDN to CoAP. 
Overview [CORE]). |
     ...    |expected| Check 4. The Property(s) and its value from the 
UPDATE request message shall be included in the response from Step 6a
(5.2.1.2 Update behavior [RT]. |
     ...    |expected| Check 5. The value UPDATED in Step 4 and the 
value RETRIEVED in Step 10 shall be the same (8.4.2 Update. Processing by the 
OIC Server [CORE]). |
     ...    |expected| Check 7. In the absence of an "if" query the 
Default Interface shall be used (7.1.4.2.3 OIC Resource Interface [CORE]). |
     ...    |expected| Check 10. Every message with a payload body shall 
contain a Content-Format option with a numeric value from Table 32
(12.2.3 Content Type negotiation [CORE]). | 
=========================================

According to the test description of CT1_2_3::1, CTT (I mean ITT) will send CON 
UPDATE request message (== CoAP POST message), however I can't see any POST 
message, rather I could only find GET messages.

Is this situation ok, or am I doing something wrong about this?

Thanks & regards

- Kevin


-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2016.0.7539 / Virus Database: 4556/12074 - Release Date: 04/21/16

Reply via email to