Further info: This is a literal ipv6 adsress:
FEDC:BA98:7654:3210:FEDC:BA98:7654:3210 Same embedded *within* a URL: http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index.html If you add zone to the literal, you use %. Add it to the URL and you must use %25. No? Anyway the point is that the addr field is systematically ambiguous. Is it a literal or a URL? I don't see how it can be the latter. G On Jan 25, 2018 2:27 PM, "Gregg Reynolds" <[email protected]> wrote: Hi Dave, Thanks for taking the time to respond. Comments/questions below. On Jan 22, 2018 3:51 PM, "Dave Thaler" <[email protected]> wrote: Below *From:* [email protected] [mailto: [email protected]] *On Behalf Of *Gregg Reynolds *Sent:* Monday, January 22, 2018 11:37 AM *To:* iotivity-dev <[email protected]> *Subject:* [dev] percent encoding IPv6 endpoints OCMapZoneIdToLinkLocalEndpoint (in ocstack.c) percent-encodes the IPv6 address included in the OCEndpointPayload of an OCResourcePayload struct: if (OC_STACK_OK == OCGetLinkLocalZoneId(ifindex, &zoneId)) { assert(zoneId != NULL); // put zoneId to end of addr OICStrcat(eps->addr, OC_MAX_ADDR_STR_SIZE, "%25"); OICStrcat(eps->addr, OC_MAX_ADDR_STR_SIZE, zoneId); OICFree(zoneId); } As I understand it such encoding is only there for e.g. browsers. It’s needed anywhere that the link/interface is not passed separately or implicitly. Not sure what "it" refers to. I'm talking about percent-encoding, not zone or interface. It is not needed in CoAP messages, where addressing info is formatted such that no percent-encoding is needed. A message on the wire is already in the context of a link/interface so it does not appear on the wire. Percent encoding the endpoint address forces clients to percent-decode the endpoint in order to use it in e.g. a GET request. That smells fishy to me. Using a percent-encoded address in OCDoRequest fails. OCDoRequest passes the interface in the ifindex field of the OCDevAddr pointed to by the “destination” argument, so it’s not needed in the URI (it would be needed if there were no destination argument). OCDoRequest could be updated to optionally allow it, as long as it’s consistent with the aforementioned ifindex field (note: a zone id and an ifindex are not inherently the same thing, but it is possible to check for consistency). RFC 66874 "updates the URI syntax specification [RFC3986 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc3986&data=02%7C01%7Cdthaler%40microsoft.com%7C9953322791e74315608308d561cf8131%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636522466260349920&sdata=c9V4P8fKhR6IQXElrgE7XZwyitBsl87mgkhu4BqTvQ8%3D&reserved=0>] by adding syntax to allow a zone identifier to be included in a literal IPv6 address **within a URI**." (emphasis added). The addr field of OCEndpointPayload is not a URI, hence should not be percent-encoded. What am I missing? Is there some other question you have? So, I get a response to a discovery request. I use one of the eps to construct a request. This fails, because the EP is percent-encoding. This is technically wrong, because percent-encoding only applies to literal ipv6 addresses *within* a URL. The URL in the EP is not a URL. This is a bug. G Dave Gregg
_______________________________________________ iotivity-dev mailing list [email protected] https://lists.iotivity.org/mailman/listinfo/iotivity-dev
