On Mon, Jul 24, 2017 at 12:31 AM, Thiago Macieira <[email protected]
> wrote:
> On Sunday, 23 July 2017 21:11:32 PDT 조병탁 wrote:
> > Thank you for response.
> >
> > In my understand, iotivity has no issue when user uses iotivity open
> source
> > as client and server. Because iotivity 1.2.(server - oic1.1) will
> response
> > error as '4.06 Not Acceptable' about request of iotivity 1.3.0(client -
> > ocf1.0). at this time, iotivity 1.3.0 will resend discovery packet
> > according to oic1.1. spec. automatically.
>
> Hmm... you're right. I was incorrect in stating the messagae would simply
> be
> dropped. The spec is very clear: RFC 7252 section 5.4.1 "Critical/Elective"
> says
>
> o Unrecognized options of class "critical" that occur in a
> Confirmable request MUST cause the return of a 4.02 (Bad Option)
> response. This response SHOULD include a diagnostic payload
> describing the unrecognized option(s) (see Section 5.5.2).
>
> > But some other implementation will response '4.02 Bad Option' or will
> drop
> > request message. in this case, iotivity 1.3.0 can not resend discovery
> > request automatically.
>
> Looks like we've been sending the wrong reply, but so long as a reply was
> sent, we can detect that there's a device there and try to resend without
> the
> version option.
>
> Dropping the request is wrong too, against the CoAP spec.
What about:
"Unrecognized options of class "critical" that occur in a Non-
confirmable message MUST cause the message to be rejected
(Section 4.3 <https://tools.ietf.org/html/rfc7252#section-4.3>)."
And section 4.3 says "Rejecting a Non-
confirmable message MAY involve sending a matching Reset message, and
apart from the Reset message the rejected message MUST be silently
ignored."
> Maybe it's something
> we can ask the OCF CTT to test, by sending a CoAP packet with another,
> unknown
> CoAP header option and see if the device replies with 4.02. We should even
> make it mandatory on the OCF spec to include the diagnostic payload that
> the
> CoAP spec mentions and leaves only as a recommendation (SHOULD). That way,
> the
> device that sent the request can quickly determine what option it was that
> was
> rejected and, from that, conclude the age of the remote device.
>
> > In conclusion, if someone uses other implemenation (oic 1.1), they
> should do
> > something accoridng to version negotiation.
> > and about 'Elective option' i mentioned, i've thought, there should be no
> > CoAP option parsing error.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect - Intel Open Source Technology Center
>
> _______________________________________________
> iotivity-dev mailing list
> [email protected]
> https://lists.iotivity.org/mailman/listinfo/iotivity-dev
>
_______________________________________________
iotivity-dev mailing list
[email protected]
https://lists.iotivity.org/mailman/listinfo/iotivity-dev
