Re: [core] Call for reviews of draft-castellani-core-http-mapping
"Dijk, Esko" <esko.dijk@philips.com> Wed, 27 March 2013 08:26 UTC
Return-Path: <esko.dijk@philips.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 183F121F90A4 for <core@ietfa.amsl.com>; Wed, 27 Mar 2013 01:26:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.849
X-Spam-Level:
X-Spam-Status: No, score=-4.849 tagged_above=-999 required=5 tests=[AWL=1.750, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhiPdqZpHOnU for <core@ietfa.amsl.com>; Wed, 27 Mar 2013 01:26:48 -0700 (PDT)
Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe005.messaging.microsoft.com [207.46.163.28]) by ietfa.amsl.com (Postfix) with ESMTP id DEC2621F906A for <core@ietf.org>; Wed, 27 Mar 2013 01:26:46 -0700 (PDT)
Received: from mail21-co9-R.bigfish.com (10.236.132.250) by CO9EHSOBE005.bigfish.com (10.236.130.68) with Microsoft SMTP Server id 14.1.225.23; Wed, 27 Mar 2013 08:26:45 +0000
Received: from mail21-co9 (localhost [127.0.0.1]) by mail21-co9-R.bigfish.com (Postfix) with ESMTP id 8CD68C00C7; Wed, 27 Mar 2013 08:26:45 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI
X-SpamScore: -34
X-BigFish: VPS-34(zz98dI15d6O9371I9251Jc89bh542I14ffI217bIzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL8275dhz2dh2a8h668h839h947hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1155h)
Received: from mail21-co9 (localhost.localdomain [127.0.0.1]) by mail21-co9 (MessageSwitch) id 1364372804524646_9293; Wed, 27 Mar 2013 08:26:44 +0000 (UTC)
Received: from CO9EHSMHS011.bigfish.com (unknown [10.236.132.230]) by mail21-co9.bigfish.com (Postfix) with ESMTP id 7CED11C0333; Wed, 27 Mar 2013 08:26:44 +0000 (UTC)
Received: from mail.philips.com (157.55.7.222) by CO9EHSMHS011.bigfish.com (10.236.130.21) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 27 Mar 2013 08:26:43 +0000
Received: from 011-DB3MMR1-021.MGDPHG.emi.philips.com (10.128.28.103) by 011-DB3MMR1-006.MGDPHG.emi.philips.com (10.128.28.56) with Microsoft SMTP Server (TLS) id 14.2.328.11; Wed, 27 Mar 2013 08:26:16 +0000
Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.99]) by 011-DB3MMR1-021.MGDPHG.emi.philips.com ([fe80::f066:9203:e7da:3658%11]) with mapi id 14.02.0328.011; Wed, 27 Mar 2013 08:26:16 +0000
From: "Dijk, Esko" <esko.dijk@philips.com>
To: "Rahman, Akbar" <Akbar.Rahman@InterDigital.com>, Carsten Bormann <cabo@tzi.org>, Floris Van den Abeele <floris.vandenabeele@intec.ugent.be>
Thread-Topic: [core] Call for reviews of draft-castellani-core-http-mapping
Thread-Index: AQHOKN+l05uJa1Rmo0etQcuHR51NeJi4EViAgAAFkoCAACVFgIAA86Rw
Date: Wed, 27 Mar 2013 08:26:15 +0000
Message-ID: <031DD135F9160444ABBE3B0C36CED618BF6A00@011-DB3MPN2-082.MGDPHG.emi.philips.com>
References: <0C9867A6-AED5-4063-88AE-E9D1C6CDE75E@tzi.org><5151B631.9050607@intec.ugent.be> <AC9A2F2A-3C15-4689-8BAD-FC440E44840B@tzi.org> <D60519DB022FFA48974A25955FFEC08C05017696@SAM.InterDigital.com>
In-Reply-To: <D60519DB022FFA48974A25955FFEC08C05017696@SAM.InterDigital.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [194.171.252.103]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: philips.com
Cc: core WG <core@ietf.org>
Subject: Re: [core] Call for reviews of draft-castellani-core-http-mapping
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Mar 2013 08:26:49 -0000
Hi all, In my view it would be best to base ourselves on the coap-14 definitions. These already mention that translations between protocols can be done, so that should be ok for our HTTP-CoAP translation purpose. But I agree with Akbar we still should have some text in draft-castellani-core-http-mapping that shows what the general definitions mean when applied to HTTP-to-CoAP request translation. However, there was some discussion among the authors of draft-castellani-core-http-mapping about one part of the coap-14 definition: "Unlike a forward-proxy, the client may not be aware that it is communicating with a reverse-proxy;" This was considered too vague. The client's "awareness" is not something where we can technically distinguish forward/reverse proxies. The second part of the sentence is more useful: " a reverse-proxy receives requests as if it was the origin server for the target resource". This is also what the longer definition in draft-castellani-core-http-mapping tries to say. And [I-D.ietf-httpbis-p1-messaging] also defines the distinction in this manner. Floris, I hope this makes the distinction clear? In a next version we could refer to the coap-14 definitions and add some text that applies these in the specific HTTP-CoAP translation context. So the authors value a clear technical distinction between forward and reverse proxy without having to debate on "awareness" and whether the client can or will do URI structure interpretation. regards, Esko -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Rahman, Akbar Sent: Tuesday, March 26, 2013 18:26 To: Carsten Bormann Cc: core WG Subject: Re: [core] Call for reviews of draft-castellani-core-http-mapping Hi Carsten, With respect to your comment: Maybe draft-castellani-core-http-mapping-07.txt doesn't really need to define the terms forward-proxy and reverse-proxy, but can reference them from the core coap spec. "transparent"/intercepting proxies are not discussed in core-coap, though. Yes, the definition for forward-proxy can be referenced to the coap-14 I-D. However, the reverse-proxy definition in coap-14 does not explicitly discuss HTTP-CoAP translation (which is the key point of this I-D and the reason that we thought it was worthwhile to explicitly define reverse-proxy in this way in this I-D). Do you agree with this logic? Best Regards, Akbar -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Carsten Bormann Sent: Tuesday, March 26, 2013 11:12 AM To: Floris Van den Abeele Cc: core WG Subject: Re: [core] Call for reviews of draft-castellani-core-http-mapping On Mar 26, 2013, at 15:52, Floris Van den Abeele <floris.vandenabeele@intec.ugent.be> wrote: > Can the authors (or someone else) give clear examples of forward and reverse http/coap cross protocol proxies? core-coap-14 defines: Forward-Proxy A "forward-proxy" is an endpoint selected by a client, usually via local configuration rules, to perform requests on behalf of the client, doing any necessary translations. Some translations are minimal, such as for proxy requests for "coap" URIs, whereas other requests might require translation to and from entirely different application-layer protocols. Reverse-Proxy A "reverse-proxy" is an endpoint that stands in for one or more other server(s) and satisfies requests on behalf of these, doing any necessary translations. Unlike a forward-proxy, the client may not be aware that it is communicating with a reverse-proxy; a reverse-proxy receives requests as if it was the origin server for the target resource. ... and goes on (5.7): In an overall architecture for a Constrained RESTful Environment, proxies can serve quite different purposes. Proxies can be explicitly selected by clients, a role that we term "forward-proxy". Proxies can also be inserted to stand in for origin servers, a role that we term "reverse-proxy". Orthogonal to this distinction, a proxy can map from a CoAP request to a CoAP request (CoAP-to-CoAP proxy) or translate from or to a different protocol ("cross-proxy"). Full definitions of these terms are provided in Section 1.2. Notes: The terminology in this specification has been selected to be culturally compatible with the terminology used in the wider Web application environments, without necessarily matching it in every detail (which may not even be relevant to Constrained RESTful Environments). Not too much semantics should be ascribed to the components of the terms (such as "forward", "reverse", or "cross"). HTTP proxies, besides acting as HTTP proxies, often offer a transport protocol proxying function ("CONNECT") to enable end-to- end transport layer security through the proxy. No such function is defined for CoAP-to-CoAP proxies in this specification, as forwarding of UDP packets is unlikely to be of much value in Constrained RESTful environments. See also Section 10.2.7 for the cross-proxy case. So the point is that a client always knows when it is using a Forward-Proxy, i.e., it has explicitly chosen to talk to it as opposed to the origin server. We have the options Proxy-Uri and Proxy-Scheme that enable to express this choice explicitly: 5.7.2. Forward-Proxies CoAP distinguishes between requests made (as if) to an origin server and a request made through a forward-proxy. CoAP requests to a forward-proxy are made as normal Confirmable or Non-confirmable requests to the forward-proxy endpoint, but specify the request URI in a different way: The request URI in a proxy request is specified as a string in the Proxy-Uri Option (see Section 5.10.2), while the request URI in a request to an origin server is split into the Uri- Host, Uri-Port, Uri-Path and Uri-Query Options (see Section 5.10.1); alternatively the URI in a proxy request can be assembled from a Proxy-Scheme option and the split options mentioned. There is no way in a URI to specify the use of a forward-proxy. Which forward-proxy is used is decided by the client based on local information (which may include information gleaned from the URI, of course). The URI continues to looks For a reverse-proxy, the client might be thinking it is talking to the actual origin server: The URI directly points to the reverse-proxy, but instead of serving its resource directly, the reverse-proxy defers to an origin server (or another reverse proxy!). 5.7.3. Reverse-Proxies Reverse-proxies do not make use of the Proxy-Uri or Proxy-Scheme options, but need to determine the destination (next hop) of a request from information in the request and information in their configuration. E.g., a reverse-proxy might offer various resources the existence of which it has learned through resource discovery as if they were its own resources. The reverse-proxy is free to build a namespace for the URIs that identify these resources. A reverse- proxy may also build a namespace that gives the client more control over where the request goes, e.g. by embedding host identifiers and port numbers into the URI path of the resources offered. draft-castellani-core-http-mapping-07.txt also alludes to the fact that there may be "transparent" (intercepting) entities intervening on the path to the origin server and acting a bit like reverse-proxies, except that the network provider has chosen to interpose them as opposed to the client. Of course, all these types can be combined on a path to an origin server: A client can use a forward-proxy to talk to a reverse-proxy, with any number of additional reverse-proxies (and "transparent" (intercepting) proxies) on the way to the origin server. Maybe draft-castellani-core-http-mapping-07.txt doesn't really need to define the terms forward-proxy and reverse-proxy, but can reference them from the core coap spec. "transparent"/intercepting proxies are not discussed in core-coap, though. Grüße, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.
- [core] Call for reviews of draft-castellani-core-… Carsten Bormann
- Re: [core] Call for reviews of draft-castellani-c… Floris Van den Abeele
- Re: [core] Call for reviews of draft-castellani-c… Carsten Bormann
- Re: [core] Call for reviews of draft-castellani-c… Carsten Bormann
- Re: [core] Call for reviews of draft-castellani-c… Carsten Bormann
- Re: [core] Call for reviews of draft-castellani-c… Rahman, Akbar
- Re: [core] Call for reviews of draft-castellani-c… Dijk, Esko
- Re: [core] Call for reviews of draft-castellani-c… Dijk, Esko
- Re: [core] Call for reviews of draft-castellani-c… peter van der Stok
- Re: [core] Call for reviews of draft-castellani-c… Dijk, Esko
- Re: [core] Call for reviews of draft-castellani-c… Klaus Hartke
- Re: [core] Call for reviews of draft-castellani-c… Dijk, Esko
- Re: [core] Call for reviews of draft-castellani-c… Dijk, Esko
- Re: [core] Call for reviews of draft-castellani-c… peter van der Stok