Ok I read this thread through again and checked the code and now I understand your point. You’re saying that OICStrcat(eps->addr, OC_MAX_ADDR_STR_SIZE, "%25"); should be OICStrcat(eps->addr, OC_MAX_ADDR_STR_SIZE, "%"); in OCMapZoneIdToLinkLocalEndpoint() because eps->addr should be an IP literal string, not a URL authority component string. either that or it’s ambiguous which it should be, because the OCEndpointPayload definition in octypes.h doesn’t say what it is, which means it’s an API issue since it’s not documented how to use the public API.
I’ll keep looking to refresh my memory about which one it’s supposed to be in the code. Dave From: Dave Thaler Sent: Thursday, January 25, 2018 1:18 PM To: 'Gregg Reynolds' <[email protected]> Cc: iotivity-dev <[email protected]> Subject: RE: [dev] percent encoding IPv6 endpoints From: Gregg Reynolds [mailto:[email protected]] Sent: Thursday, January 25, 2018 12:39 PM To: Dave Thaler <[email protected]<mailto:[email protected]>> Cc: iotivity-dev <[email protected]<mailto:[email protected]>> Subject: RE: [dev] percent encoding IPv6 endpoints 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? Correct. %26 is the pct-encoded version of ‘%’, so %25 is how you encode the ‘%’ in the authority portion of a URI. 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. I don’t follow. What addr field are you talking about? I’m not aware of anything that’s ambiguous. Dave On Jan 25, 2018 2:27 PM, "Gregg Reynolds" <[email protected]<mailto:[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]<mailto:[email protected]>> wrote: Below From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Gregg Reynolds Sent: Monday, January 22, 2018 11:37 AM To: iotivity-dev <[email protected]<mailto:[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
