On segunda-feira, 25 de julho de 2016 09:26:21 PDT Abhishek Sharma wrote: > > I don't think we should do that. I propose to do it like I said and simply > > insert the foreign payload as a Byte Text property inside the CBOR > > payload. > > That looks more like a workaround where clients would have to extract say a > XML payload from a cbor payload. That is unnecessary overhead and > duplicates thing that are already taken care by communication protocol for > ex: "Accept", "Content-type" type headers.
The point is that you don't know what the format is and shouldn't try to interpret. If translation is an optional feature, then you need to figure out a way to transmit the untranslated data. > > Supporting other content types/formats means you're doing a generic proxy, > > which you yourself excluded. > > I am not sure what you mean here by "a generic proxy". We are adding a > CoAP-HTTP proxy for IoTivity which is CoAP spec compliant. And also we are > adding extra content-type support based on requirements you specified. but > I am not ready to reinvent the wheel and add duplicate parameters in > payload. You're describing a hybrid of two things. Let me explain how I see it: 1) a pure CoAP-HTTP proxy, as defined by RFC 7252 section 10.1 This takes Proxy-Uri and/or Proxy-Scheme headers, but this functionality is not an OCF service, is not restricted to CBOR, does not follow the OCF payload structure, and does not translate. It should be provided on a separate port number and an OCF resource should be listed in /oic/res that gives information on how to connect to the proxy. 2) an OCF resource that fetches remote resources and responds This is a regular OCF resource, listed in /oic/res, that responds to OCF- defined CRUDN requests and replies, obeys OCF security requirements including encryption and ACL matching. The payloads in requests and replies are formatted according to the OCF specification, using CBOR. In the previous emails, I got really confused about whether you're referring to #1 or #2. You talk about parts of #1 and parts of #2, which in my mind doesn't make sense and is just confusing me. Please clarify what you mean by describing the packet flow. What does a client send, what does the proxy reply with? > > Ok, so do it now. HTTPS is not optional. > > As I pointed out earlier, your concern that "you will have to review entire > codebase twice" is not valid as only a single file will change. A > subsequent patch will add support for https, but not in the first proxy > release. Not acceptable. HTTPS is not optional. Therefore, the first release must have it. I will review the code when you have support for HTTPS. Not before. > > Because you said you're not going to follow them. You said it's an OCF > > resource, accepting CBOR payloads and returning CBOR payloads. Then we > > should use OCF CRUDN to initiate the requests and obtain responses, with > > payloads formatted according to OCF rules. That means we don't need to > > use Proxy-URI headers because that's not part of the OCF protocol. > > I never said that we are not going to follow spec. As it currently stand, a > virtual resource for proxy is added to aid in discovery of proxy by > IoTivity clients (since spec does not mandate discovery procedure). Once > discovered, all communications are done as mandated in specifications. > Receiving only CBOR payload does not make it an OCF service. Ok, so you're describing scenario #1 above. Then you need to describe the security features of this proxy. Will it be accessible unencrypted, encrypted (DTLS) or both? How will it apply ACLs? How does one configure ACLs for it? How will the end-to-end payload encryption affect this, if at all? If it won't, please explain if the proxy can be accessed via an OCF intermediary and, if it is possible, how that will work . -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
