Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ibwh0-00082L-96; Sun, 30 Sep 2007 07:10:34 -0400 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1Ibwgy-0007rf-Vx for apps-review-confirm+ok@megatron.ietf.org; Sun, 30 Sep 2007 07:10:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ibwgy-0007mM-G7 for apps-REVIEW@ietf.org; Sun, 30 Sep 2007 07:10:32 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ibwgx-0007oh-4C for apps-REVIEW@ietf.org; Sun, 30 Sep 2007 07:10:32 -0400 Received: (qmail invoked by alias); 30 Sep 2007 11:10:20 -0000 Received: from p508F85C2.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.133.194] by mail.gmx.net (mp011) with SMTP; 30 Sep 2007 13:10:20 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19daDdrqx9dAByoEbNxgmD10tybWlCF0PYXkrnEJ1 VLEzQgsMUegiNY Message-ID: <46FF8417.6090203@gmx.de> Date: Sun, 30 Sep 2007 13:10:15 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP References: <46E93396.2090003@gmx.net> <46FF783D.7090904@gmx.net> In-Reply-To: <46FF783D.7090904@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Chris Newman , keyprov@ietf.org, apps-REVIEW@ietf.org X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org Hi, thanks for the overview. If that document indeed argues against new methods, for new URI schemes and for usage of WSDL it seems it needs to be either fixed or marked historic. Maybe it's something for HTTPbis to look at? Best regards, Julian _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ibvu6-0007oN-JR; Sun, 30 Sep 2007 06:20:02 -0400 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1Ibvu4-0007nn-Kh for apps-review-confirm+ok@megatron.ietf.org; Sun, 30 Sep 2007 06:20:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ibvtz-0007nK-Qb for apps-REVIEW@ietf.org; Sun, 30 Sep 2007 06:19:55 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ibvts-000788-PB for apps-REVIEW@ietf.org; Sun, 30 Sep 2007 06:19:49 -0400 Received: (qmail invoked by alias); 30 Sep 2007 10:19:45 -0000 Received: from 1.106.113.82.net.de.o2.com (EHLO [10.68.253.41]) [82.113.106.1] by mail.gmx.net (mp048) with SMTP; 30 Sep 2007 12:19:45 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+wdQBL1OmwrejigCDkcbg0U3wWArnAc7VhX4nW7z 6iVdoZpOmLxkIP Message-ID: <46FF783D.7090904@gmx.net> Date: Sun, 30 Sep 2007 12:19:41 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: apps-REVIEW@ietf.org Subject: Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP References: <46E93396.2090003@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: keyprov@ietf.org, Chris Newman X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org Hi Lisa, Hi Chris, Hi all, thank you Chris for the pointer to RFC 3205 (BCP 56). I now read it and it is indeed a very interesting document. Too bad that I didn't came across it earlier. Reading through that document I got the impression that the suggestions that can be found in there are not exercised by today's protocol designs. There are a couple of issues that require consideration when defining an HTTP transport: (a) MIME-types. I believe we are doing fine with the usage of XML and the registration of a new mime type. http://tools.ietf.org/html/draft-ietf-pkix-scvp-33 on the other hand uses different mime types for request and resonse messages. I don't think that this is necessary. (b) No new HTTP method seems to be needed (We don't do that in the DSKPP draft anyway) (c) New port number for DSKPP since the usage is so different from ordinary HTTP webbrowsing (This is quite controversal when it comes to firewall traversal and might require more discussions. See http://www1.ietf.org/mail-archive/web/apps-review/current/msg00090.html) None of the protocols I have been working on defines a new port. Can you give a reference to a recently developed protocol that carries XML on top of HTTP that uses a new port number? (d) New URI scheme (Currently we use the HTTP/HTTPS schemes but that does not seem to be inline with the recommendations in BCP 56.) Neither HELD, SCVP, LoST nor DSKPP define a new URI scheme. In LoST we had a URL registration in the document once, see Section 16.5 of draft-ietf-ecrit-lost-03, but removed it later (co-author of that document is Ted Hardie, the former Applications Area Director). (e) WSDL Usage: Lisa and Chris do not see WSDL as something being useful. In fact, I haven't found a person who argued in favor of WSDL. Hence, I believe we should avoid it. (f) Error Codes: RFC 3205 points to the problems of defining error codes when applications are layered on top of HTTP. The suggestion is to essentially only use 200 (for complete success) and 500 (for complete failure) at the HTTP layer and to use "application" specific error codes inside the layer application itself. We are essentially doing this. The only other error message that is being mentioned is 403 and since it is independent of the DSKPP protocol interaction it should be fine as well. (g) HTTP client, proxy and server code: We added text regarding the expected behavior of clients, proxies and server in Section 5 of http://www.ietf.org/internet-drafts/draft-ietf-keyprov-dskpp-00.txt. I guess we are doing fine there. I am OK with (a), (b), (e), (f) and (g). I am not sure about (c) and (d). Help needed. Ciao Hannes PS: Regarding Mime-Types: In KEYPROV with the DSKPP document we should use application/dskpp+xml instead of application/vnd.ietf.keyprov.dskpp+xml The IANA registry for the MIME type should look similar to the one in Section 17.2 of draft-ietf-ecrit-lost-06. We also need to add a registry for the schema and the namespace (see Section 11.1 of draft-ietf-geopriv-http-location-delivery-02.txt for the URN sub-namespace registration, and Section 11.2 of for the XML schema registration). Chris Newman wrote: > I expect HTTP bindings to address the concerns raised in BCP 56. > Unless the primary client for your protocol is a web browser, I would > strongly encourage registering a separate port. In the SMTP world, > the primary source of interoperability problems is application-level > gateways/firewalls. At this point it's inevitable we'll end up with > intrusive firewalls on port 80 that will break anything beyond stock > browser-based HTTP. I encourage new HTTP-based protocols to register > a separate port so they have the opportunity to avoid such damage and > interoperability problems. It also simplifies responsible firewall > operation by enabling port-based service restrictions that are more > scalable and less intrusive. > > I have yet to see any evidence that WSDL is useful in practice but > that may be due to my lack of experience with web services. > > I find Relax NG and/or XML schema useful for XML-based > protocols/formats whether or not they are built on top of HTTP. My > understanding is that Relax NG is better for extensible entity-based > XML formats, whereas XML Schema is better for XML formats with strong > value typing. > > I haven't reviewed the DSKPP draft yet. > > - Chris > > Hannes Tschofenig wrote on 9/13/07 14:56 +0200: > >> Hi all, >> >> I would like to solicit feedback regarding the HTTP binding described in >> DSKPP: >> http://www.ietf.org/internet-drafts/draft-ietf-keyprov-dskpp-00.txt >> >> I went through a couple of documents that describe an HTTP binding and >> noticed all of them are slightly different. If you, for example, take >> a look >> at another recent work, namely HELD, from the GEOPRIV working group >> then you >> will notice that the author incorporated a WSDL binding. The draft is >> here: >> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-http-location-delivery >> >> -01.txt >> >> Do people on this list have an opinion about the content they would >> like to >> see in these type of documents? >> What is the opinion regarding the usage of WSDL? >> >> Ciao >> Hannes > > > > _______________________________________________ > APPS-REVIEW mailing list > APPS-REVIEW@ietf.org > https://www1.ietf.org/mailman/listinfo/apps-review _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iay8G-00010b-Pe; Thu, 27 Sep 2007 14:30:40 -0400 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1Iay8G-0000yq-B7 for apps-review-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 14:30:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iay8C-0000gw-1Z for apps-review@ietf.org; Thu, 27 Sep 2007 14:30:36 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iay81-0002Xr-FB for apps-review@ietf.org; Thu, 27 Sep 2007 14:30:25 -0400 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l8RIUODZ021690 for ; Thu, 27 Sep 2007 18:30:24 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JP100B01H2KWG00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for apps-review@ietf.org; Thu, 27 Sep 2007 12:30:24 -0600 (MDT) Received: from [10.0.1.3] ([10.1.110.5]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JP1004FVI2IFD90@mail-amer.sun.com> for apps-review@ietf.org; Thu, 27 Sep 2007 12:30:21 -0600 (MDT) Date: Thu, 27 Sep 2007 11:30:34 -0700 From: Chris Newman To: Applications Area Review List Message-id: MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Subject: [APPS-REVIEW] Guidelines for protocol designers using UDP (fwd) X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org This document is likely to set the bar for use of UDP in application protocols. I'd like someone on apps-review to formally review this for me. It would be especially helpful if that someone has implemented or specified UDP-based protocols in the past. Thanks, - Chris ---------- Forwarded Message ---------- Date: Thursday, September 27, 2007 13:33 +0200 From: Magnus Westerlund To: Internet Area , ops-area@ietf.org, discuss@apps.ietf.org, routing-discussion@ietf.org, SAAG CC: tsvwg Subject: Guidelines for protocol designers using UDP Hi, In the TSVWG we have been developing a guidelines document for UDP. It is intended for protocol designers that consider using UDP in their protocol. We do hope that it will help remove some of the misconception that UDP is a simple protocol to use. It might look that way because most of the features necessary for being acceptable to deploy on the general internet needs to be specified by the one using UDP. It is also something that the Transport ADs already started using as help in explaining why and what to fix when we put a DISCUSS on your document that is using UDP. http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-udp-guidelines-03.txt So TSVWG is still working on this document but we are now considering it quite complete. So we are looking for feedback from you. Are there things that are unclear, missing, wrong, etc. Please provide your feedback to TSVWG (tsvwg@ietf.org). Thanks Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- ---------- End Forwarded Message ---------- _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ5ub-0003Ca-Q0; Sat, 22 Sep 2007 10:24:49 -0400 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1IZ5ua-0003CV-KF for apps-review-confirm+ok@megatron.ietf.org; Sat, 22 Sep 2007 10:24:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ5ua-00035f-Ad for apps-REVIEW@ietf.org; Sat, 22 Sep 2007 10:24:48 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IZ5uP-0006nk-0g for apps-REVIEW@ietf.org; Sat, 22 Sep 2007 10:24:38 -0400 Received: (qmail invoked by alias); 22 Sep 2007 14:24:20 -0000 Received: from p54987604.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.118.4] by mail.gmx.net (mp018) with SMTP; 22 Sep 2007 16:24:20 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX180r8pEg2k0M2miYfoEEjY7MZr9diIP1kP9eqcUfa AzqqyTjsP7Qfa+ Message-ID: <46F52594.305@gmx.net> Date: Sat, 22 Sep 2007 16:24:20 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Barry Leiba Subject: Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP References: <46E93396.2090003@gmx.net> <46F4E31A.2050700@gmx.net> <3EF861EB9E7E71DCF1B32820@Uranus.local> In-Reply-To: <3EF861EB9E7E71DCF1B32820@Uranus.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: apps-REVIEW@ietf.org X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org Hi Barry, Barry Leiba wrote: >> I am not sure whether the separate port number idea will find a lot of >> excitement since the downside is that a network operator that just >> does not >> care about the specific protocol (even through he does not mind >> allowing end >> hosts to run it) will essentially block it. > > Hannes, I'm not sure I understand what you're saying here, so maybe > you should explain more. What I read it as saying is that you don't > like using a separate port because you *want* to sneak through > firewalls without telling the firewall administrators. There be > dragons, and that was Chris's point. A protocol that looks like HTTP > but is used for a different purpose should be on a different port. > > Actually, I've had this argument with people within my company too, > and it might be that we aren't clear about what the port-number list > *is*: it should be more like a list that maps *applications*, rather > than *protocols*, to ports. In most cases, that's the same. But with > SMTP and HTTP, at least, it's not. > I agree that it would be nice to allow administrators to make these type of decisions. In other areas in the IETF folks also had the idea that the network administrators are going to configure their networks in such a way that the protocols would work. SIP and NAT/Firewall traversal is a good example. It took a while to realize that this is not a good approach. DSKPP is an application layer protocols that allows an end point to retrieve keying material for usage with other protocols. Typically, the client on an end host will interact with a server in it's home network. If I am in a hotel network and want to obtain new keying material for usage with my VPN client and the network administrator of the hotel network does not know the port number used by DSKPP then it might happen that I just cannot use the protocol. Now, there are also other protocols flying around in this space; actually a large number of protocols in this identity management space that happen to run on top of HTTP without using an additional port (at least to my knowledge). I don't see why these protocol should work in all environments (where HTTP traffic is allowed to bypass a middlebox) but a protocol developed within the IETF isn't just because there is this idea of a "clean architecture". Does my reasoning make sense to you? Ciao Hannes > Barry _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ5h6-0002Td-TJ; Sat, 22 Sep 2007 10:10:52 -0400 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1IZ5h5-0002TT-LP for apps-review-confirm+ok@megatron.ietf.org; Sat, 22 Sep 2007 10:10:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ5h5-0002Gi-7N for apps-REVIEW@ietf.org; Sat, 22 Sep 2007 10:10:51 -0400 Received: from e31.co.us.ibm.com ([32.97.110.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZ5gz-000440-K4 for apps-REVIEW@ietf.org; Sat, 22 Sep 2007 10:10:45 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e31.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l8MEAY6e025648 for ; Sat, 22 Sep 2007 10:10:34 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l8MEAYpN412342 for ; Sat, 22 Sep 2007 08:10:34 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l8MEAXug000566 for ; Sat, 22 Sep 2007 08:10:34 -0600 Received: from poplar (poplar.watson.ibm.com [9.2.40.57]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l8MEAXQI000555; Sat, 22 Sep 2007 08:10:33 -0600 Received: from wecm-9-67-175-208.wecm.ibm.com ([9.67.175.208]) by poplar.watson.ibm.com (IMF.2005.07.16.1050.haw) with SMTP ID IMFd1190470262.1691; Sat, 22 Sep 2007 10:11:02 -0400 Date: Sat, 22 Sep 2007 10:10:52 -0400 From: Barry Leiba To: Hannes Tschofenig Subject: Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP Message-ID: <3EF861EB9E7E71DCF1B32820@Uranus.local> In-Reply-To: <46F4E31A.2050700@gmx.net> References: <46E93396.2090003@gmx.net> <46F4E31A.2050700@gmx.net> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: apps-REVIEW@ietf.org X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org > I am not sure whether the separate port number idea will find a lot of > excitement since the downside is that a network operator that just does not > care about the specific protocol (even through he does not mind allowing end > hosts to run it) will essentially block it. Hannes, I'm not sure I understand what you're saying here, so maybe you should explain more. What I read it as saying is that you don't like using a separate port because you *want* to sneak through firewalls without telling the firewall administrators. There be dragons, and that was Chris's point. A protocol that looks like HTTP but is used for a different purpose should be on a different port. Actually, I've had this argument with people within my company too, and it might be that we aren't clear about what the port-number list *is*: it should be more like a list that maps *applications*, rather than *protocols*, to ports. In most cases, that's the same. But with SMTP and HTTP, at least, it's not. Barry _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ4ok-0005mF-PK; Sat, 22 Sep 2007 09:14:42 -0400 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1IZ4oj-0005kp-JU for apps-review-confirm+ok@megatron.ietf.org; Sat, 22 Sep 2007 09:14:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ4oj-0005gg-5b for apps-REVIEW@ietf.org; Sat, 22 Sep 2007 09:14:41 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IZ4oa-0002tV-7W for apps-REVIEW@ietf.org; Sat, 22 Sep 2007 09:14:32 -0400 Received: (qmail invoked by alias); 22 Sep 2007 13:14:30 -0000 Received: from p508FBB99.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.187.153] by mail.gmx.net (mp051) with SMTP; 22 Sep 2007 15:14:30 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX189QUUJDc89KQcKo7yQdGcsSZilK7WKT/4xp7D4fL ssDgfqcDtQjGKT Message-ID: <46F51534.6090805@gmx.de> Date: Sat, 22 Sep 2007 15:14:28 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP References: <46E93396.2090003@gmx.net> <46F4E31A.2050700@gmx.net> <46F4E9C9.8090103@gmx.de> <46F50E51.103@gmx.net> In-Reply-To: <46F50E51.103@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Chris Newman , apps-REVIEW@ietf.org X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org Hannes Tschofenig wrote: > ... > I don't think that there is a difference between the two with this > respect. For protocols we don't put too many constraints on data types > in the schema anyway since there will not be any validation of incoming > messages since you have to parse them anyway. > ... That's what I thought as well. > Relax NG vs. XML schema: We currently already have the XML schema in the > document and nobody in the group suggested to change it. > When we picked a Relax NG schema for LoST (a different protocol) in the > ECRIT WG some folks did not like it due to the lack of available tools. > Programmers told us that they translated the Relax NG schema found in > the document into a XML schema. So, the Relax NG schema was not of great > value to them even though we thought it was much more convenient to use. In WebDAV, we used DTD fragments to describe the formats (with the known shortcomings with respect to namespaces, element ordering and extensibility). Replacing this with XML Schema would be IMHO a non-starter, because XML Schema has the same constraints with respect to extensibility as DTDs. Relax NG in its compact notation form looks very good, both because it's actually readable in a spec, and because it does all "we" (people working on WebDAV specs) need -- it works well with namespaces, and extensibility can actually be defined properly. People who actually want to validate programmatically -- and in protocols it's not really clears that this is a good idea -- can either use the few Relax NG validators, or convert to XML Schema (or DTD) using Trang. And that's IMHO the biggest advantage: the RNC format is as readable as DTD, but it's better for defining protocol constraints than XNL Schema (1.0). And people who need XML Schema can still easily convert to it. I think that's one of many things the AtomPub WG got right in RFC4287. Best regards, Julian _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ4MO-0003aE-AE; Sat, 22 Sep 2007 08:45:24 -0400 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1IZ4MN-0003a9-D5 for apps-review-confirm+ok@megatron.ietf.org; Sat, 22 Sep 2007 08:45:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ4MN-0003a1-3T for apps-REVIEW@ietf.org; Sat, 22 Sep 2007 08:45:23 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IZ4MG-0004tR-QF for apps-REVIEW@ietf.org; Sat, 22 Sep 2007 08:45:23 -0400 Received: (qmail invoked by alias); 22 Sep 2007 12:45:05 -0000 Received: from p54987604.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.118.4] by mail.gmx.net (mp042) with SMTP; 22 Sep 2007 14:45:05 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19X9phFJMNXRpJezGR+khMKxE+YiGF+qVaXRI9HLU T4uZpP4tiVnNzd Message-ID: <46F50E51.103@gmx.net> Date: Sat, 22 Sep 2007 14:45:05 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Julian Reschke Subject: Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP References: <46E93396.2090003@gmx.net> <46F4E31A.2050700@gmx.net> <46F4E9C9.8090103@gmx.de> In-Reply-To: <46F4E9C9.8090103@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Chris Newman , apps-REVIEW@ietf.org X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org Hi Julian, Julian Reschke wrote: > Hannes Tschofenig wrote: >>> I find Relax NG and/or XML schema useful for XML-based >>> protocols/formats whether or not they are built on top of HTTP. My >>> understanding is that Relax NG is better for extensible entity-based >>> XML formats, whereas XML Schema is better for XML formats with >>> strong value typing. >> We will certainly make use of an XML schema. > > ... > > Out of curiosity? How exactly is XML Schema superior with respect to > data typing? > I don't think that there is a difference between the two with this respect. For protocols we don't put too many constraints on data types in the schema anyway since there will not be any validation of incoming messages since you have to parse them anyway. Relax NG vs. XML schema: We currently already have the XML schema in the document and nobody in the group suggested to change it. When we picked a Relax NG schema for LoST (a different protocol) in the ECRIT WG some folks did not like it due to the lack of available tools. Programmers told us that they translated the Relax NG schema found in the document into a XML schema. So, the Relax NG schema was not of great value to them even though we thought it was much more convenient to use. Ciao Hannes > Best regards, Julian > > > > _______________________________________________ > APPS-REVIEW mailing list > APPS-REVIEW@ietf.org > https://www1.ietf.org/mailman/listinfo/apps-review _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ1vK-00086V-9F; Sat, 22 Sep 2007 06:09:18 -0400 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1IZ1vI-00083l-7G for apps-review-confirm+ok@megatron.ietf.org; Sat, 22 Sep 2007 06:09:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ1vH-00083W-Rk for apps-REVIEW@ietf.org; Sat, 22 Sep 2007 06:09:15 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IZ1vH-0007Ha-6d for apps-REVIEW@ietf.org; Sat, 22 Sep 2007 06:09:15 -0400 Received: (qmail invoked by alias); 22 Sep 2007 10:09:14 -0000 Received: from p508FBB99.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.187.153] by mail.gmx.net (mp051) with SMTP; 22 Sep 2007 12:09:14 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19/HfMbsct/1ZrDbfbi9FrrsLWjnVcRE39QW5v5uq +t0Q7j/B1ph7z9 Message-ID: <46F4E9C9.8090103@gmx.de> Date: Sat, 22 Sep 2007 12:09:13 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP References: <46E93396.2090003@gmx.net> <46F4E31A.2050700@gmx.net> In-Reply-To: <46F4E31A.2050700@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Chris Newman , apps-REVIEW@ietf.org X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org Hannes Tschofenig wrote: >> I find Relax NG and/or XML schema useful for XML-based >> protocols/formats whether or not they are built on top of HTTP. My >> understanding is that Relax NG is better for extensible entity-based >> XML formats, whereas XML Schema is better for XML formats with strong >> value typing. > We will certainly make use of an XML schema. > ... Out of curiosity? How exactly is XML Schema superior with respect to data typing? Best regards, Julian _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ1UH-0007ya-Rj; Sat, 22 Sep 2007 05:41:21 -0400 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1IZ1UG-0007yB-Lb for apps-review-confirm+ok@megatron.ietf.org; Sat, 22 Sep 2007 05:41:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ1UC-0007ot-Ib for apps-REVIEW@ietf.org; Sat, 22 Sep 2007 05:41:16 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IZ1Ty-0000ya-87 for apps-REVIEW@ietf.org; Sat, 22 Sep 2007 05:41:08 -0400 Received: (qmail invoked by alias); 22 Sep 2007 09:40:41 -0000 Received: from p54987604.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.118.4] by mail.gmx.net (mp058) with SMTP; 22 Sep 2007 11:40:41 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18k8MocjBQkDDJCpFK04Kk3FN1h9cwtsT1nBNk6Nk o3KlUQQDbCi25B Message-ID: <46F4E31A.2050700@gmx.net> Date: Sat, 22 Sep 2007 11:40:42 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Chris Newman Subject: Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP References: <46E93396.2090003@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: apps-REVIEW@ietf.org X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org Hi Chris, thanks for the response. Chris Newman wrote: > I expect HTTP bindings to address the concerns raised in BCP 56. I will read through BCP 56. > Unless the primary client for your protocol is a web browser, I would > strongly encourage registering a separate port. In the SMTP world, > the primary source of interoperability problems is application-level > gateways/firewalls. At this point it's inevitable we'll end up with > intrusive firewalls on port 80 that will break anything beyond stock > browser-based HTTP. I encourage new HTTP-based protocols to register > a separate port so they have the opportunity to avoid such damage and > interoperability problems. It also simplifies responsible firewall > operation by enabling port-based service restrictions that are more > scalable and less intrusive. I am not sure whether the separate port number idea will find a lot of excitement since the downside is that a network operator that just does not care about the specific protocol (even through he does not mind allowing end hosts to run it) will essentially block it. > > I have yet to see any evidence that WSDL is useful in practice but > that may be due to my lack of experience with web services. I have received this type of feedback from a couple of different sides already. > > I find Relax NG and/or XML schema useful for XML-based > protocols/formats whether or not they are built on top of HTTP. My > understanding is that Relax NG is better for extensible entity-based > XML formats, whereas XML Schema is better for XML formats with strong > value typing. We will certainly make use of an XML schema. > > I haven't reviewed the DSKPP draft yet. > I need to see whether I need to make changes based on the above-mentioned BCP. Hence, I would advice to wait a bit. Ciao Hannes > - Chris > > Hannes Tschofenig wrote on 9/13/07 14:56 +0200: > >> Hi all, >> >> I would like to solicit feedback regarding the HTTP binding described in >> DSKPP: >> http://www.ietf.org/internet-drafts/draft-ietf-keyprov-dskpp-00.txt >> >> I went through a couple of documents that describe an HTTP binding and >> noticed all of them are slightly different. If you, for example, take >> a look >> at another recent work, namely HELD, from the GEOPRIV working group >> then you >> will notice that the author incorporated a WSDL binding. The draft is >> here: >> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-http-location-delivery >> >> -01.txt >> >> Do people on this list have an opinion about the content they would >> like to >> see in these type of documents? >> What is the opinion regarding the usage of WSDL? >> >> Ciao >> Hannes _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYpzF-0001KU-4A; Fri, 21 Sep 2007 17:24:33 -0400 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1IYpzE-0001Jz-JZ for apps-review-confirm+ok@megatron.ietf.org; Fri, 21 Sep 2007 17:24:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYpzE-0001Jq-86 for apps-REVIEW@ietf.org; Fri, 21 Sep 2007 17:24:32 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYpz8-0007cy-1k for apps-REVIEW@ietf.org; Fri, 21 Sep 2007 17:24:32 -0400 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l8LLNxPU009459 for ; Fri, 21 Sep 2007 21:23:59 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JOQ00B01LVCOZ00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for apps-REVIEW@ietf.org; Fri, 21 Sep 2007 15:23:59 -0600 (MDT) Received: from [10.0.1.3] ([10.1.110.5]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JOQ00KP8M3QX6C0@mail-amer.sun.com>; Fri, 21 Sep 2007 15:23:54 -0600 (MDT) Date: Fri, 21 Sep 2007 14:23:56 -0700 From: Chris Newman Subject: Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP In-reply-to: <46E93396.2090003@gmx.net> To: Hannes Tschofenig , apps-REVIEW@ietf.org Message-id: MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <46E93396.2090003@gmx.net> X-Spam-Score: -1.0 (-) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org I expect HTTP bindings to address the concerns raised in BCP 56. Unless the primary client for your protocol is a web browser, I would strongly encourage registering a separate port. In the SMTP world, the primary source of interoperability problems is application-level gateways/firewalls. At this point it's inevitable we'll end up with intrusive firewalls on port 80 that will break anything beyond stock browser-based HTTP. I encourage new HTTP-based protocols to register a separate port so they have the opportunity to avoid such damage and interoperability problems. It also simplifies responsible firewall operation by enabling port-based service restrictions that are more scalable and less intrusive. I have yet to see any evidence that WSDL is useful in practice but that may be due to my lack of experience with web services. I find Relax NG and/or XML schema useful for XML-based protocols/formats whether or not they are built on top of HTTP. My understanding is that Relax NG is better for extensible entity-based XML formats, whereas XML Schema is better for XML formats with strong value typing. I haven't reviewed the DSKPP draft yet. - Chris Hannes Tschofenig wrote on 9/13/07 14:56 +0200: > Hi all, > > I would like to solicit feedback regarding the HTTP binding described in > DSKPP: > http://www.ietf.org/internet-drafts/draft-ietf-keyprov-dskpp-00.txt > > I went through a couple of documents that describe an HTTP binding and > noticed all of them are slightly different. If you, for example, take a look > at another recent work, namely HELD, from the GEOPRIV working group then you > will notice that the author incorporated a WSDL binding. The draft is here: > http://www.ietf.org/internet-drafts/draft-ietf-geopriv-http-location-delivery > -01.txt > > Do people on this list have an opinion about the content they would like to > see in these type of documents? > What is the opinion regarding the usage of WSDL? > > Ciao > Hannes _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYgOF-0003O2-6B; Fri, 21 Sep 2007 07:09:43 -0400 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1IYgOE-0003Ld-Cx for apps-review-confirm+ok@megatron.ietf.org; Fri, 21 Sep 2007 07:09:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYgOA-0003Hs-7q for apps-REVIEW@ietf.org; Fri, 21 Sep 2007 07:09:38 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IYgO9-0007fO-Hp for apps-REVIEW@ietf.org; Fri, 21 Sep 2007 07:09:37 -0400 Received: (qmail invoked by alias); 21 Sep 2007 11:09:33 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp029) with SMTP; 21 Sep 2007 13:09:33 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+5iht88N65grJD4ZcaLo5F9kGXH2cpSB0lIFS7wX RrGOnZxvJRL+tW Message-ID: <46F3A66C.5060606@gmx.net> Date: Fri, 21 Sep 2007 13:09:32 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hannes Tschofenig References: <46ECF3F8.2030303@gmx.net> In-Reply-To: <46ECF3F8.2030303@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: apps-REVIEW@ietf.org Subject: [APPS-REVIEW] Re: Review of HTTP Binding for DSKPP X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org Resend... If you think that the DSKPP draft is fine (with respect to the HTTP binding) please also drop me a note. Ciao Hannes Hannes Tschofenig wrote: > Hi all, > > I would like to solicit feedback regarding the HTTP binding described > in DSKPP: > http://www.ietf.org/internet-drafts/draft-ietf-keyprov-dskpp-00.txt > > I went through a couple of documents that describe an HTTP binding and > noticed all of them are slightly different. If you, for example, take > a look at another recent work, namely HELD, from the GEOPRIV working > group then you will notice that the author incorporated a WSDL > binding. The draft is here: > http://www.ietf.org/internet-drafts/draft-ietf-geopriv-http-location-delivery-01.txt > > > Do people on this list have an opinion about the content they would > like to see in these type of documents? > What is the opinion regarding the usage of WSDL? > > Ciao > Hannes > > > > _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWqDC-0007eq-3g; Sun, 16 Sep 2007 05:14:42 -0400 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1IWqDA-0007ek-Fi for apps-review-confirm+ok@megatron.ietf.org; Sun, 16 Sep 2007 05:14:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWqD5-0007eZ-IY for apps-REVIEW@ietf.org; Sun, 16 Sep 2007 05:14:35 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IWqD4-0003fi-0X for apps-REVIEW@ietf.org; Sun, 16 Sep 2007 05:14:35 -0400 Received: (qmail invoked by alias); 16 Sep 2007 09:14:32 -0000 Received: from p5498768E.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.118.142] by mail.gmx.net (mp057) with SMTP; 16 Sep 2007 11:14:32 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/O/5JwN8bO7yqhExAewXWQvBWvJB9iNnl5dHlkgW HKaQBHy5zEBEJf Message-ID: <46ECF3F8.2030303@gmx.net> Date: Sun, 16 Sep 2007 11:14:32 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: apps-REVIEW@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: [APPS-REVIEW] Review of HTTP Binding for DSKPP X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org Hi all, I would like to solicit feedback regarding the HTTP binding described in DSKPP: http://www.ietf.org/internet-drafts/draft-ietf-keyprov-dskpp-00.txt I went through a couple of documents that describe an HTTP binding and noticed all of them are slightly different. If you, for example, take a look at another recent work, namely HELD, from the GEOPRIV working group then you will notice that the author incorporated a WSDL binding. The draft is here: http://www.ietf.org/internet-drafts/draft-ietf-geopriv-http-location-delivery-01.txt Do people on this list have an opinion about the content they would like to see in these type of documents? What is the opinion regarding the usage of WSDL? Ciao Hannes _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWPpo-0001Ra-Ej; Sat, 15 Sep 2007 01:04:48 -0400 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1IVoFj-0000Cr-7b for apps-review-confirm+ok@megatron.ietf.org; Thu, 13 Sep 2007 08:57:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVoFf-0000CJ-3c for apps-REVIEW@ietf.org; Thu, 13 Sep 2007 08:56:59 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IVoFe-0004jU-JM for apps-REVIEW@ietf.org; Thu, 13 Sep 2007 08:56:59 -0400 Received: (qmail invoked by alias); 13 Sep 2007 12:56:56 -0000 Received: from ip-90-186-10-19.web.vodafone.de (EHLO [90.186.10.19]) [90.186.10.19] by mail.gmx.net (mp032) with SMTP; 13 Sep 2007 14:56:56 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18B7TJpV0IBPeeIC0vF3EtYLWUMeCbUb53VTeX4Bt dLBUQL9kX9tuU9 Message-ID: <46E93396.2090003@gmx.net> Date: Thu, 13 Sep 2007 14:56:54 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: apps-REVIEW@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-Mailman-Approved-At: Sat, 15 Sep 2007 01:04:46 -0400 Cc: Subject: [APPS-REVIEW] Review of HTTP Binding for DSKPP X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org Hi all, I would like to solicit feedback regarding the HTTP binding described in DSKPP: http://www.ietf.org/internet-drafts/draft-ietf-keyprov-dskpp-00.txt I went through a couple of documents that describe an HTTP binding and noticed all of them are slightly different. If you, for example, take a look at another recent work, namely HELD, from the GEOPRIV working group then you will notice that the author incorporated a WSDL binding. The draft is here: http://www.ietf.org/internet-drafts/draft-ietf-geopriv-http-location-delivery-01.txt Do people on this list have an opinion about the content they would like to see in these type of documents? What is the opinion regarding the usage of WSDL? Ciao Hannes _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISAuF-0007Sx-Jr; Mon, 03 Sep 2007 08:19:51 -0400 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1ISAuE-0007Ss-5w for apps-review-confirm+ok@megatron.ietf.org; Mon, 03 Sep 2007 08:19:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISAuD-0007Sk-Qy for APPS-REVIEW@ietf.org; Mon, 03 Sep 2007 08:19:49 -0400 Received: from dxgarr.dir.garr.it ([193.206.158.1]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISAuC-0001Dw-U4 for APPS-REVIEW@ietf.org; Mon, 03 Sep 2007 08:19:49 -0400 Received: from localhost (localhost [127.0.0.1]) by dxgarr.dir.garr.it (8.12.11/8.12.11) with ESMTP id l83CJaHw194974; Mon, 3 Sep 2007 14:19:36 +0200 (CEST) Date: Mon, 3 Sep 2007 14:19:37 +0200 (CEST) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.local To: Larry Masinter Subject: Re: [APPS-REVIEW] Fwd: SMS URI spec question In-Reply-To: <04C2DBA376A5274EAFD744566642E45A015D9956@namail1.corp.adobe.com> Message-ID: References: <04C2DBA376A5274EAFD744566642E45A015D9956@namail1.corp.adobe.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: APPS-REVIEW@ietf.org, Larry Masinter , Paul Hoffman , Martin Duerst , jwz@jwz.org X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org On Sun, 2 Sep 2007, Larry Masinter wrote: > I think when we revised the uri scheme registration rules, we gave up on > the idea (most likely W3C policy) of trying to discourage URI schemes > with narrow applicability by limiting registration, because the result > was widespread use of unregistered schemes. And SMS is different enough > from email to not fit nicely into mailto. True, and this was agreed also by the draft editors during the quite long discussion which wa suseful to prepare the current draft. >So I have no doubt that it > should be registered, and just would focus on ensuring that the > definition is clear enough that the players know what to do -- and not > to mandate behavior that is unlikely to be implemented. I fully agree. > There are several players, including those who write software that > interprets URIs to send SMS messages (handset protocol stack), or > construct URIs from parameters (browsers) or supply those parameters > (html forms) or the URIs themselves. > > Is the supplier of a URI (or a form with a SMS target) expected to be > aware of the nature of URI-interpreter's handling of long SMS messages? > (I can see how they might know about the SMS receiver since they supply > the number.) I think the answer is YES. Has the "long SMS" handling is quite odd, implementers should take care of its possible effects (for example strings being cut into separate SMS messages!). > I think it comes down to whether you require the SMS-sender to always > use the long-message standard (even if the lower level stack doesn't). > If not, then it would be convenient to warn html form authors that sms > messages longer than the single message length limit might not be sent > interoperably. Also true. > > > > -----Original Message----- > From: Thomas Roessler [mailto:tlr@w3.org] > Sent: Sunday, September 02, 2007 06:12 AM Pacific Standard Time > To: Lisa Dusseault > Cc: APPS-REVIEW@ietf.org; Martin Duerst; Larry Masinter; jwz@jwz.org; Paul Hoffman > Subject: Re: [APPS-REVIEW] Fwd: SMS URI spec question > > On 2007-08-31 08:47:28 -0700, Lisa Dusseault wrote: > >> http://www.ietf.org/internet-drafts/draft-wilde-sms-uri-12.txt >> >> has a bunch of URL parameters which are instructions not only to >> the agent originating the SMS message (similar to the subject in >> mailto:me@example.com;subject=HelloWorld ) but also instructions >> to the SMSC (SMS Center). Some features even instruct the SMSC >> to send multiple messages, or gateway to a different protocol, or >> both. > > Looking through the specification, there seems to be an > architectural decision in here to conflate the use of SMS facilities > to send text messages (for which a separate SMS URI scheme would > indeed seem very useful) with the use of these facilities as > infrastructure to do other things for which more or less > transport-independent URI schemes have already been defined. > > For these latter use case, having an infrastructure-specific URI > scheme is worrying. > > Specifically, I've got some questions about the relation of this > specification to the tel:, fax:, mailto: URI schemes. > > Starting with e-mail, the example in 2.4 has a phone number that's > (apparently) not used, which suggests that something might be wrong > with the proposed URL syntax in the first place. > > More importantly, however, what's the rationale why a mailto URL > couldn't be used for the precise same use case? Re-reading RFC > 2368, I don't see any reason why a "mailto:" URI couldn't be > "dereferenced" by sending specially crafted SMSes that cause the > SMSC to produce and send the corresponding e-mail message. On the > other hand, taking a form submission use case, it would seem like a > local policy decision on the user-agent side whether an e-mail to an > Internet mailbox is gatewayed through SMS or sent through SMTP > directly (or maybe through avian carriers). > > Similarly, what's the rationale why the fax URI scheme (which comes > with an extension mechanism) couldn't be used to specify message > content along with a fax-ness of the recipient's number, without > ever using an SMS URI? > > Similarly, what's the rationale why the voice services can't be > handled by the same approach? > > I would also like to understand the rationale for specifying SMSCs > as part of the URI in more detail. At best, this is a > layer-violating fix for SMS-related routing issues. At worst, we're > just specifying mobile network specific URIs for classical Internet > services which can conveniently be tied to a particular network > operator. Which would be worrying. > > As Larry already pointed out, section 3 feels out of place, as it > seems to specify implementation details for a particular type of URI > handler. If this section remains part of the document, however, it > might also be useful to say a word or two about safe and unsafe HTTP > methods. You really don't want to trigger an SMS with a GET. > > Regards, > -- > Thomas Roessler, W3C +33-4-89063488 > > > _______________________________________________ > APPS-REVIEW mailing list > APPS-REVIEW@ietf.org > https://www1.ietf.org/mailman/listinfo/apps-review > ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISAgB-0002qh-9E; Mon, 03 Sep 2007 08:05:19 -0400 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1IRv38-0003hV-3k for apps-review-confirm+ok@megatron.ietf.org; Sun, 02 Sep 2007 15:23:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRv37-0003hN-QH for APPS-REVIEW@ietf.org; Sun, 02 Sep 2007 15:23:57 -0400 Received: from exprod6og54.obsmtp.com ([64.18.1.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IRv36-0006VR-Du for APPS-REVIEW@ietf.org; Sun, 02 Sep 2007 15:23:57 -0400 Received: from source ([192.150.11.134]) by exprod6ob54.postini.com ([64.18.5.12]) with SMTP; Sun, 02 Sep 2007 12:22:58 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l82JLLIQ004574; Sun, 2 Sep 2007 12:21:21 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l82JMvRC020112; Sun, 2 Sep 2007 12:22:57 -0700 (PDT) Received: from namail1.corp.adobe.com ([10.8.192.62]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Sep 2007 12:22:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [APPS-REVIEW] Fwd: SMS URI spec question Date: Sun, 2 Sep 2007 12:22:56 -0700 Message-ID: <04C2DBA376A5274EAFD744566642E45A015D9956@namail1.corp.adobe.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [APPS-REVIEW] Fwd: SMS URI spec question Thread-Index: AcftYveagRo0+8TkREuZKmew+WNbUwAM7LSU From: "Larry Masinter" To: "Thomas Roessler" , "Lisa Dusseault" X-OriginalArrivalTime: 02 Sep 2007 19:22:57.0165 (UTC) FILETIME=[AAE96BD0:01C7ED96] X-Spam-Score: -4.0 (----) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db X-Mailman-Approved-At: Mon, 03 Sep 2007 08:05:18 -0400 Cc: Paul Hoffman , Martin Duerst , jwz@jwz.org, Larry Masinter , APPS-REVIEW@ietf.org X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org I think when we revised the uri scheme registration rules, we gave up on = the idea (most likely W3C policy) of trying to discourage URI schemes = with narrow applicability by limiting registration, because the result = was widespread use of unregistered schemes. And SMS is different enough = from email to not fit nicely into mailto. So I have no doubt that it = should be registered, and just would focus on ensuring that the = definition is clear enough that the players know what to do -- and not = to mandate behavior that is unlikely to be implemented. There are several players, including those who write software that = interprets URIs to send SMS messages (handset protocol stack), or = construct URIs from parameters (browsers) or supply those parameters = (html forms) or the URIs themselves. Is the supplier of a URI (or a form with a SMS target) expected to be = aware of the nature of URI-interpreter's handling of long SMS messages? = (I can see how they might know about the SMS receiver since they supply = the number.) =20 I think it comes down to whether you require the SMS-sender to always = use the long-message standard (even if the lower level stack doesn't). = If not, then it would be convenient to warn html form authors that sms = messages longer than the single message length limit might not be sent = interoperably. -----Original Message----- From: Thomas Roessler [mailto:tlr@w3.org] Sent: Sunday, September 02, 2007 06:12 AM Pacific Standard Time To: Lisa Dusseault Cc: APPS-REVIEW@ietf.org; Martin Duerst; Larry Masinter; jwz@jwz.org; = Paul Hoffman Subject: Re: [APPS-REVIEW] Fwd: SMS URI spec question On 2007-08-31 08:47:28 -0700, Lisa Dusseault wrote: > http://www.ietf.org/internet-drafts/draft-wilde-sms-uri-12.txt > > has a bunch of URL parameters which are instructions not only to > the agent originating the SMS message (similar to the subject in=20 > mailto:me@example.com;subject=3DHelloWorld ) but also instructions > to the SMSC (SMS Center). Some features even instruct the SMSC > to send multiple messages, or gateway to a different protocol, or > both. Looking through the specification, there seems to be an architectural decision in here to conflate the use of SMS facilities to send text messages (for which a separate SMS URI scheme would indeed seem very useful) with the use of these facilities as infrastructure to do other things for which more or less transport-independent URI schemes have already been defined.=20 For these latter use case, having an infrastructure-specific URI scheme is worrying. Specifically, I've got some questions about the relation of this specification to the tel:, fax:, mailto: URI schemes. Starting with e-mail, the example in 2.4 has a phone number that's (apparently) not used, which suggests that something might be wrong with the proposed URL syntax in the first place. More importantly, however, what's the rationale why a mailto URL couldn't be used for the precise same use case? Re-reading RFC 2368, I don't see any reason why a "mailto:" URI couldn't be "dereferenced" by sending specially crafted SMSes that cause the SMSC to produce and send the corresponding e-mail message. On the other hand, taking a form submission use case, it would seem like a local policy decision on the user-agent side whether an e-mail to an Internet mailbox is gatewayed through SMS or sent through SMTP directly (or maybe through avian carriers). Similarly, what's the rationale why the fax URI scheme (which comes with an extension mechanism) couldn't be used to specify message content along with a fax-ness of the recipient's number, without ever using an SMS URI? Similarly, what's the rationale why the voice services can't be handled by the same approach? I would also like to understand the rationale for specifying SMSCs as part of the URI in more detail. At best, this is a layer-violating fix for SMS-related routing issues. At worst, we're just specifying mobile network specific URIs for classical Internet services which can conveniently be tied to a particular network operator. Which would be worrying. As Larry already pointed out, section 3 feels out of place, as it seems to specify implementation details for a particular type of URI handler. If this section remains part of the document, however, it might also be useful to say a word or two about safe and unsafe HTTP methods. You really don't want to trigger an SMS with a GET. Regards, --=20 Thomas Roessler, W3C +33-4-89063488 _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IS6h6-0002Ff-Aw; Mon, 03 Sep 2007 03:50:00 -0400 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1IS6h5-0002Ag-1N for apps-review-confirm+ok@megatron.ietf.org; Mon, 03 Sep 2007 03:49:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IS6h0-00025G-TN for APPS-REVIEW@ietf.org; Mon, 03 Sep 2007 03:49:54 -0400 Received: from homer.w3.org ([128.30.52.30]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IS6gz-0000Vz-O7 for APPS-REVIEW@ietf.org; Mon, 03 Sep 2007 03:49:53 -0400 Received: from raktajino.does-not-exist.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id AEF504F014; Mon, 3 Sep 2007 03:49:52 -0400 (EDT) Received: from roessler by raktajino.does-not-exist.org with local (Exim 4.66) (envelope-from ) id 1IS6gx-0003Pk-Vw; Mon, 03 Sep 2007 09:49:51 +0200 Date: Mon, 3 Sep 2007 09:49:51 +0200 From: Thomas Roessler To: Larry Masinter Subject: Re: [APPS-REVIEW] Fwd: SMS URI spec question Message-ID: <20070903074951.GA3497@raktajino.does-not-exist.org> Mail-Followup-To: Larry Masinter , Lisa Dusseault , APPS-REVIEW@ietf.org, Martin Duerst , Larry Masinter , jwz@jwz.org, Paul Hoffman References: <04C2DBA376A5274EAFD744566642E45A015D9956@namail1.corp.adobe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <04C2DBA376A5274EAFD744566642E45A015D9956@namail1.corp.adobe.com> User-Agent: Mutt/1.5.16 (2007-07-25) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: APPS-REVIEW@ietf.org, Larry Masinter , Paul Hoffman , Martin Duerst , jwz@jwz.org X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org On 2007-09-02 12:22:56 -0700, Larry Masinter wrote: > I think when we revised the uri scheme registration rules, we > gave up on the idea (most likely W3C policy) of trying to > discourage URI schemes with narrow applicability by limiting > registration, because the result was widespread use of > unregistered schemes. And SMS is different enough from email to > not fit nicely into mailto. Umh... I must have been unclear. I'm *not* suggesting that "sms" be replaced by "mailto", or that the scheme be rejected. However, I am suggesting that "SMS to be turned into Internet e-mail message at SMSC" is maybe better dealt with by a mailto URI; likewise for the "text-to-voice" and "text-to-fax" gateway functionalities and the tel and fax URI schemes. Regards, -- Thomas Roessler, W3C +33-4-89063488 _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRpFj-00014U-S4; Sun, 02 Sep 2007 09:12:35 -0400 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1IRpFi-00011W-9v for apps-review-confirm+ok@megatron.ietf.org; Sun, 02 Sep 2007 09:12:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRpFe-0000wA-4q for APPS-REVIEW@ietf.org; Sun, 02 Sep 2007 09:12:30 -0400 Received: from homer.w3.org ([128.30.52.30]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IRpFd-0003JY-LM for APPS-REVIEW@ietf.org; Sun, 02 Sep 2007 09:12:30 -0400 Received: from raktajino.does-not-exist.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 9F6C74F2FB; Sun, 2 Sep 2007 09:12:28 -0400 (EDT) Received: from roessler by raktajino.does-not-exist.org with local (Exim 4.66) (envelope-from ) id 1IRpFb-0002hd-TZ; Sun, 02 Sep 2007 15:12:27 +0200 Date: Sun, 2 Sep 2007 15:12:27 +0200 From: Thomas Roessler To: Lisa Dusseault Subject: Re: [APPS-REVIEW] Fwd: SMS URI spec question Message-ID: <20070902131227.GV3497@raktajino.does-not-exist.org> Mail-Followup-To: Lisa Dusseault , APPS-REVIEW@ietf.org, Martin Duerst , Larry Masinter , jwz@jwz.org, Paul Hoffman References: <46D7579B.1020302@berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-07-25) X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Paul Hoffman , Martin Duerst , jwz@jwz.org, Larry Masinter , APPS-REVIEW@ietf.org X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org On 2007-08-31 08:47:28 -0700, Lisa Dusseault wrote: > http://www.ietf.org/internet-drafts/draft-wilde-sms-uri-12.txt > > has a bunch of URL parameters which are instructions not only to > the agent originating the SMS message (similar to the subject in > mailto:me@example.com;subject=HelloWorld ) but also instructions > to the SMSC (SMS Center). Some features even instruct the SMSC > to send multiple messages, or gateway to a different protocol, or > both. Looking through the specification, there seems to be an architectural decision in here to conflate the use of SMS facilities to send text messages (for which a separate SMS URI scheme would indeed seem very useful) with the use of these facilities as infrastructure to do other things for which more or less transport-independent URI schemes have already been defined. For these latter use case, having an infrastructure-specific URI scheme is worrying. Specifically, I've got some questions about the relation of this specification to the tel:, fax:, mailto: URI schemes. Starting with e-mail, the example in 2.4 has a phone number that's (apparently) not used, which suggests that something might be wrong with the proposed URL syntax in the first place. More importantly, however, what's the rationale why a mailto URL couldn't be used for the precise same use case? Re-reading RFC 2368, I don't see any reason why a "mailto:" URI couldn't be "dereferenced" by sending specially crafted SMSes that cause the SMSC to produce and send the corresponding e-mail message. On the other hand, taking a form submission use case, it would seem like a local policy decision on the user-agent side whether an e-mail to an Internet mailbox is gatewayed through SMS or sent through SMTP directly (or maybe through avian carriers). Similarly, what's the rationale why the fax URI scheme (which comes with an extension mechanism) couldn't be used to specify message content along with a fax-ness of the recipient's number, without ever using an SMS URI? Similarly, what's the rationale why the voice services can't be handled by the same approach? I would also like to understand the rationale for specifying SMSCs as part of the URI in more detail. At best, this is a layer-violating fix for SMS-related routing issues. At worst, we're just specifying mobile network specific URIs for classical Internet services which can conveniently be tied to a particular network operator. Which would be worrying. As Larry already pointed out, section 3 feels out of place, as it seems to specify implementation details for a particular type of URI handler. If this section remains part of the document, however, it might also be useful to say a word or two about safe and unsafe HTTP methods. You really don't want to trigger an SMS with a GET. Regards, -- Thomas Roessler, W3C +33-4-89063488 _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRnvA-0003PA-1T; Sun, 02 Sep 2007 07:47:16 -0400 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1IR8sP-0003DD-0o for apps-review-confirm+ok@megatron.ietf.org; Fri, 31 Aug 2007 11:57:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR8sO-0003D5-Mt for APPS-REVIEW@ietf.org; Fri, 31 Aug 2007 11:57:40 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IR8sN-00028y-Cw for APPS-REVIEW@ietf.org; Fri, 31 Aug 2007 11:57:40 -0400 Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7VFvZnJ067662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Aug 2007 08:57:37 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <46D7579B.1020302@berkeley.edu> Date: Fri, 31 Aug 2007 08:56:47 -0700 To: Lisa Dusseault , APPS-REVIEW@ietf.org, Martin Duerst , Larry Masinter , jwz@jwz.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-Mailman-Approved-At: Sun, 02 Sep 2007 07:47:15 -0400 Cc: Subject: [APPS-REVIEW] Re: Fwd: SMS URI spec question X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org At 8:47 AM -0700 8/31/07, Lisa Dusseault wrote: >The SMS URI draft: > >http://www.ietf.org/internet-drafts/draft-wilde-sms-uri-12.txt > >has a bunch of URL parameters which are instructions not only to the >agent originating the SMS message (similar to the subject in >mailto:me@example.com;subject=HelloWorld ) >but also instructions to the SMSC (SMS Center). Some features even >instruct the SMSC to send multiple messages, or gateway to a >different protocol, or both. > >I'm hoping that Apps reviewers plus mailto schema experts can either >quell my qualms or inform them. Any thoughts? We have had no problems with mailto: and headers that I know of. The only complaint I ever hear is that it doesn't handle MIME messages. _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRnvA-0003Pi-C5; Sun, 02 Sep 2007 07:47:16 -0400 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1IReDK-00089M-5M for apps-review-confirm+ok@megatron.ietf.org; Sat, 01 Sep 2007 21:25:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IReDF-000897-V5 for APPS-REVIEW@ietf.org; Sat, 01 Sep 2007 21:25:17 -0400 Received: from wx-out-0506.google.com ([66.249.82.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IReDE-0002q1-Q3 for APPS-REVIEW@ietf.org; Sat, 01 Sep 2007 21:25:17 -0400 Received: by wx-out-0506.google.com with SMTP id s8so1122412wxc for ; Sat, 01 Sep 2007 18:25:16 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=fs4Tjf4pj0tPBVT7FHp1v0Ie80AT5VFf76ysiQE4QNhf7g490JXVKgABniMYEScRNuMUHu8oAaBjwHOv6yNuiExtz6/VqkAP52eQ844BZ8ChtQxeQraCgcJ29k5ovKt8NF77S5BDQy61lFEhqWRRgCqkUE4B03wsOT3Zwc7S7CY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=Q6UFotJq076dE3JWWfeqvciWM9YlD7sfqWNlp/XBVOnHXL76Cvpba/vfuaA5BpksLDTqhqBvpwa8uBwFrm5hzmxOibN7hpiR3Io8v+IPRj+v5T2l8bk6Y3TNLLFeS+t99fHP6rvOrGSQ97sQq/GAPwULWGlwiyOJQ18T1b4WiLI= Received: by 10.70.113.16 with SMTP id l16mr5418578wxc.1188696315983; Sat, 01 Sep 2007 18:25:15 -0700 (PDT) Received: by 10.70.125.3 with HTTP; Sat, 1 Sep 2007 18:25:15 -0700 (PDT) Message-ID: Date: Sat, 1 Sep 2007 18:25:15 -0700 From: "Larry Masinter" To: "Erik Wilde" In-Reply-To: <46D85C53.8070304@berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46D7579B.1020302@berkeley.edu> <000001c7ebf7$7d342f90$779c8eb0$@org> <46D85C53.8070304@berkeley.edu> X-Google-Sender-Auth: 5e73b105e32666fc X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-Mailman-Approved-At: Sun, 02 Sep 2007 07:47:15 -0400 Cc: APPS-REVIEW@ietf.org, antti.vaha-sipila@nokia.com, Paul Hoffman , Martin Duerst , jwz@jwz.org Subject: [APPS-REVIEW] Re: Fwd: SMS URI spec question X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org > > I'm uncomfortable with the vague way in which "SMS messages can > > be concatenated to form longer messages" and the length limit, > > especially since you're expecting clients to dynamically generate > > sms messages for things like form submission. I think you either > > need to define the length limit and how it applies, or else define > > how, given a sms URI with a really long message body, how to turn > > it into a sequence of sms messages. > > on the technical side, there are various ways how to encode a longer > message as a sequence of sms messages, and for example, various device > manufacturers of mobile phones choose various ways of doing this. there > is no technical limit to the number of messages that can be > concatenated, and the main concern is more about cost, because in a > typical environment, users are charged for each sms message. How does the sender of a long message know how to split up the message so that the receiver will properly interpret it? Can they ever be delivered out of order? Are the messages numbered? Is there an agreed-upon maximum length? Do you need private out-of-band information to reconstruct the original intended message from the sequence of SMS messages? You're going out of your way to specify transmission parameters for most other SMS capabilities, I'm not understanding how this part is interoperable. Larry _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRnvA-0003QJ-Ez; Sun, 02 Sep 2007 07:47:16 -0400 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1IRiMo-0001MZ-O2 for apps-review-confirm+ok@megatron.ietf.org; Sun, 02 Sep 2007 01:51:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRiMo-0001MR-CG for APPS-REVIEW@ietf.org; Sun, 02 Sep 2007 01:51:26 -0400 Received: from a.mail.sonic.net ([64.142.16.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IRiMn-0007ga-2K for APPS-REVIEW@ietf.org; Sun, 02 Sep 2007 01:51:26 -0400 Received: from [10.0.0.5] (209-204-138-37.dsl.dynamic.sonic.net [209.204.138.37]) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l825pMPq021218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 Sep 2007 22:51:22 -0700 Message-ID: <46DA4F59.2050704@berkeley.edu> Date: Sat, 01 Sep 2007 22:51:21 -0700 From: Erik Wilde User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Larry Masinter References: <46D7579B.1020302@berkeley.edu> <000001c7ebf7$7d342f90$779c8eb0$@org> <46D85C53.8070304@berkeley.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 X-Mailman-Approved-At: Sun, 02 Sep 2007 07:47:15 -0400 Cc: APPS-REVIEW@ietf.org, antti.vaha-sipila@nokia.com, Paul Hoffman , Martin Duerst , jwz@jwz.org Subject: [APPS-REVIEW] Re: Fwd: SMS URI spec question X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org hello larry. >> on the technical side, there are various ways how to encode a longer >> message as a sequence of sms messages, and for example, various device >> manufacturers of mobile phones choose various ways of doing this. there >> is no technical limit to the number of messages that can be >> concatenated, and the main concern is more about cost, because in a >> typical environment, users are charged for each sms message. > How does the sender of a long message know how to split up the message > so that the receiver will properly interpret it? Can they ever be > delivered out of order? Are the messages numbered? Is there an > agreed-upon maximum length? section 9.2.3.24.1 of http://www.3gpp.org/ftp/Specs/archive/23_series/23.040/23040-701.zip (the current sms spec) contains the details about concatenated sms messages. there is a standard format how to transmit them, but not all client use this, some use their own, in which case it is impossible to say anything about their constraints. if senders use the standard format, the following rules apply: - the sender assumes that the recipient understands the concatenated format. if the recipient does not understand it (such as the stupid iphone), the messages appear as individual messages with weird control characters in them. - delivery of sms messages in not ordered, but if the standard mechanism is used, messages can be reordered on the recipient side. if the sender or the recipient do not support the standard format, messages may appear out of order. - the standard format has a numbering scheme, which is used for ordering the messages: "Each concatenated short message contains a reference number which together with the originating address and Service Centre address allows the receiving entity to discriminate between concatenated short messages sent from different originating SMEs and/or SCs." - the standard states: "The maximum length of an uncompressed concatenated short message is 39015 (255*153) default alphabet characters, 34170 (255*134) octets or 17085 (255*67) UCS2 characters. The maximum length of a compressed concatenated message is 34170 (255*134) octets including the Compression Header and Compression Footer (see clause 3.9 and figure 9.2.3.24.1(a) below)." my guess is that most recipients (typically mobile phones) will implement smaller limits, but i have no facts about that. antti may have some details here. > Do you need private out-of-band information to reconstruct the > original intended message from the sequence of SMS messages? no, the standard format has everything that is required to make things work. > You're going out of your way to specify transmission parameters for > most other SMS capabilities, I'm not understanding how this part is > interoperable. i do understand your point that we are talking about the "maximum SMS message size", and then not say anything about it. would your comment be addressed by adding a sentence quoting the maximum size defined by the standard or the maximum size supported by the sender, and using whatever is the smaller number? thanks and cheers, dret. _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRnvA-0003PI-9X; Sun, 02 Sep 2007 07:47:16 -0400 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1IRBBh-0007UK-54 for apps-review-confirm+ok@megatron.ietf.org; Fri, 31 Aug 2007 14:25:45 -0400 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1IRBBg-0007UB-S3 for apps-review@ietf.org; Fri, 31 Aug 2007 14:25:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRB8e-0004ue-QX for APPS-REVIEW@ietf.org; Fri, 31 Aug 2007 14:22:36 -0400 Received: from bliss.ischool.berkeley.edu ([128.32.226.47]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IRB8e-0007Zu-22 for APPS-REVIEW@ietf.org; Fri, 31 Aug 2007 14:22:36 -0400 Received: from cooper.ischool.berkeley.edu (cooper.ischool.berkeley.edu [128.32.226.45]) by bliss.ischool.berkeley.edu (8.13.1/8.13.1) with ESMTP id l7VIMTAS029027; Fri, 31 Aug 2007 11:22:29 -0700 Received: from [128.32.226.195] (dhcp195.ischool.berkeley.edu [128.32.226.195]) (authenticated bits=0) by cooper.ischool.berkeley.edu (8.13.1/8.13.1) with ESMTP id l7VIMSdC024928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 31 Aug 2007 11:22:28 -0700 Message-ID: <46D85C53.8070304@berkeley.edu> Date: Fri, 31 Aug 2007 11:22:11 -0700 From: Erik Wilde User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Larry Masinter References: <46D7579B.1020302@berkeley.edu> <000001c7ebf7$7d342f90$779c8eb0$@org> In-Reply-To: <000001c7ebf7$7d342f90$779c8eb0$@org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.63 on 128.32.226.50 X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 X-TMDA-Confirmed: Fri, 31 Aug 2007 14:25:44 -0400 X-Mailman-Approved-At: Sun, 02 Sep 2007 07:47:15 -0400 Cc: APPS-REVIEW@ietf.org, antti.vaha-sipila@nokia.com, 'Paul Hoffman' , 'Martin Duerst' , jwz@jwz.org Subject: [APPS-REVIEW] Re: Fwd: SMS URI spec question X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org hello everybody. thanks for the feedback, i will try to address all the questions and will integrate these changes into a new version of the draft, which hopefully can be published very soon. > Is there a registry of pid-value, or is this it? Isn't it likely > that most of the values will be unimplemented? I suppose it's harmless. the "registry" is in the sms spec, i updated the sms spec reference to point to the latest version, and http://www.3gpp.org/ftp/Specs/archive/23_series/23.040/23040-701.zip section "9.2.3.9 TP Protocol Identifier (TP PID)" is where the identifiers are listed. it is pretty much a closed list, because it is based on bit patterns and there are only few left... and yes, most of these probably will not be implemented, but since they are part of the spec, they could be implemented. > I'm uncomfortable with the vague way in which "SMS messages can > be concatenated to form longer messages" and the length limit, > especially since you're expecting clients to dynamically generate > sms messages for things like form submission. I think you either > need to define the length limit and how it applies, or else define > how, given a sms URI with a really long message body, how to turn > it into a sequence of sms messages. on the technical side, there are various ways how to encode a longer message as a sequence of sms messages, and for example, various device manufacturers of mobile phones choose various ways of doing this. there is no technical limit to the number of messages that can be concatenated, and the main concern is more about cost, because in a typical environment, users are charged for each sms message. sadly, some devices do not give any reasonable feedback about the number of messages they are generating, the iphone for example supports sms messaging, but does not show you how many messages you will produce (and have to pay for). skype, on the other hand, faithfully shows to how many sms messages your longer message will be mapped. so i don't see a reasonable way to limit the length, but maybe it would be appropriate to say that a client SHOULD make the user aware of the number of messages that will be sent? would that address your concerns? > Sections 1.4.2& 2.5: the handling of "sms" in HTML forms references > "just as they are packaged when using a "mailto" URI, but the definition of > how > that happens is a feature of HTML and not of the URI scheme. > My recollection is that it isn't formally defined in the > W3C HTML specification, but it's also not in any (not obsolete) > IETF document. Same problem for web services. Perhaps those sections > should be marked as non-normative, and instead become informational -- > how the authors or their organizations intend to propose the > described changes to the appropriate standards bodies for the > relevant specifications. i have the same recollection as you, that there is no formal standard about this anywhere. how would be go about marking these as informal? is there a formal way of doing this, or just add a sentence at the beggining saying "the text of the following subsection is informal and for informational purposes only"? > I don't know why they need to specify section 3 at all -- every > web service SMS gateway could define its own mechanism for sending > SMS without making up funny URIs as a way of carrying the > destination information. Is this just an example? this section probably is a result of my personal frustration with how badly most clients handle unknown uri schemes, and that a more systematic way of doing this would be a good idea. would it be ok to leave it in there and mark it as informal as well? if not, i can remove it. > 4.4: of course it addresses a resource. That's why they're defining > a Resource Identifier. I'd just delete the first two sentences > and the "Instead, ". ok, done. thanks a lot and kind regards, dret. _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRnvA-0003PE-7A; Sun, 02 Sep 2007 07:47:16 -0400 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1IRAfa-0001lV-GH for apps-review-confirm+ok@megatron.ietf.org; Fri, 31 Aug 2007 13:52:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRAfa-0001kg-6K for APPS-REVIEW@ietf.org; Fri, 31 Aug 2007 13:52:34 -0400 Received: from chip2og56.obsmtp.com ([64.18.13.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IRAfY-0005Xt-W0 for APPS-REVIEW@ietf.org; Fri, 31 Aug 2007 13:52:34 -0400 Received: from source ([192.150.11.134]) by chip2ob56.postini.com ([64.18.5.12]) with SMTP; Fri, 31 Aug 2007 10:51:14 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l7VHnRIQ013129; Fri, 31 Aug 2007 10:49:27 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l7VHoxRC021859; Fri, 31 Aug 2007 10:50:59 -0700 (PDT) Received: from namail1.corp.adobe.com ([10.8.192.62]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Aug 2007 10:50:59 -0700 Received: from masinterlap06 ([10.7.240.21]) by namail1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Aug 2007 10:50:59 -0700 From: "Larry Masinter" To: "'Paul Hoffman'" , "'Lisa Dusseault'" , , "'Martin Duerst'" , References: <46D7579B.1020302@berkeley.edu> In-Reply-To: Date: Fri, 31 Aug 2007 10:50:58 -0700 Message-ID: <000001c7ebf7$7d342f90$779c8eb0$@org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acfr56fj4/1YNRm+Ryq5M8DM3mHVbAAC3Rmw Content-Language: en-us X-OriginalArrivalTime: 31 Aug 2007 17:50:59.0267 (UTC) FILETIME=[7D298130:01C7EBF7] X-Spam-Score: -3.3 (---) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-Mailman-Approved-At: Sun, 02 Sep 2007 07:47:15 -0400 Cc: antti.vaha-sipila@nokia.com, dret@berkeley.edu Subject: [APPS-REVIEW] RE: Fwd: SMS URI spec question X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org Is there a registry of pid-value, or is this it? Isn't it likely that most of the values will be unimplemented? I suppose it's harmless. I'm uncomfortable with the vague way in which "SMS messages can be concatenated to form longer messages" and the length limit, especially since you're expecting clients to dynamically generate sms messages for things like form submission. I think you either need to define the length limit and how it applies, or else define how, given a sms URI with a really long message body, how to turn it into a sequence of sms messages. Sections 1.4.2& 2.5: the handling of "sms" in HTML forms references "just as they are packaged when using a "mailto" URI, but the definition of how that happens is a feature of HTML and not of the URI scheme. My recollection is that it isn't formally defined in the W3C HTML specification, but it's also not in any (not obsolete) IETF document. Same problem for web services. Perhaps those sections should be marked as non-normative, and instead become informational -- how the authors or their organizations intend to propose the described changes to the appropriate standards bodies for the relevant specifications. I don't know why they need to specify section 3 at all -- every web service SMS gateway could define its own mechanism for sending SMS without making up funny URIs as a way of carrying the destination information. Is this just an example? 4.4: of course it addresses a resource. That's why they're defining a Resource Identifier. I'd just delete the first two sentences and the "Instead, ". Larry _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRnvA-0003PI-9X; Sun, 02 Sep 2007 07:47:16 -0400 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1IRBBh-0007UK-54 for apps-review-confirm+ok@megatron.ietf.org; Fri, 31 Aug 2007 14:25:45 -0400 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1IRBBg-0007UB-S3 for apps-review@ietf.org; Fri, 31 Aug 2007 14:25:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRB8e-0004ue-QX for APPS-REVIEW@ietf.org; Fri, 31 Aug 2007 14:22:36 -0400 Received: from bliss.ischool.berkeley.edu ([128.32.226.47]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IRB8e-0007Zu-22 for APPS-REVIEW@ietf.org; Fri, 31 Aug 2007 14:22:36 -0400 Received: from cooper.ischool.berkeley.edu (cooper.ischool.berkeley.edu [128.32.226.45]) by bliss.ischool.berkeley.edu (8.13.1/8.13.1) with ESMTP id l7VIMTAS029027; Fri, 31 Aug 2007 11:22:29 -0700 Received: from [128.32.226.195] (dhcp195.ischool.berkeley.edu [128.32.226.195]) (authenticated bits=0) by cooper.ischool.berkeley.edu (8.13.1/8.13.1) with ESMTP id l7VIMSdC024928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 31 Aug 2007 11:22:28 -0700 Message-ID: <46D85C53.8070304@berkeley.edu> Date: Fri, 31 Aug 2007 11:22:11 -0700 From: Erik Wilde User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Larry Masinter References: <46D7579B.1020302@berkeley.edu> <000001c7ebf7$7d342f90$779c8eb0$@org> In-Reply-To: <000001c7ebf7$7d342f90$779c8eb0$@org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.63 on 128.32.226.50 X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 X-TMDA-Confirmed: Fri, 31 Aug 2007 14:25:44 -0400 X-Mailman-Approved-At: Sun, 02 Sep 2007 07:47:15 -0400 Cc: APPS-REVIEW@ietf.org, antti.vaha-sipila@nokia.com, 'Paul Hoffman' , 'Martin Duerst' , jwz@jwz.org Subject: [APPS-REVIEW] Re: Fwd: SMS URI spec question X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org hello everybody. thanks for the feedback, i will try to address all the questions and will integrate these changes into a new version of the draft, which hopefully can be published very soon. > Is there a registry of pid-value, or is this it? Isn't it likely > that most of the values will be unimplemented? I suppose it's harmless. the "registry" is in the sms spec, i updated the sms spec reference to point to the latest version, and http://www.3gpp.org/ftp/Specs/archive/23_series/23.040/23040-701.zip section "9.2.3.9 TP Protocol Identifier (TP PID)" is where the identifiers are listed. it is pretty much a closed list, because it is based on bit patterns and there are only few left... and yes, most of these probably will not be implemented, but since they are part of the spec, they could be implemented. > I'm uncomfortable with the vague way in which "SMS messages can > be concatenated to form longer messages" and the length limit, > especially since you're expecting clients to dynamically generate > sms messages for things like form submission. I think you either > need to define the length limit and how it applies, or else define > how, given a sms URI with a really long message body, how to turn > it into a sequence of sms messages. on the technical side, there are various ways how to encode a longer message as a sequence of sms messages, and for example, various device manufacturers of mobile phones choose various ways of doing this. there is no technical limit to the number of messages that can be concatenated, and the main concern is more about cost, because in a typical environment, users are charged for each sms message. sadly, some devices do not give any reasonable feedback about the number of messages they are generating, the iphone for example supports sms messaging, but does not show you how many messages you will produce (and have to pay for). skype, on the other hand, faithfully shows to how many sms messages your longer message will be mapped. so i don't see a reasonable way to limit the length, but maybe it would be appropriate to say that a client SHOULD make the user aware of the number of messages that will be sent? would that address your concerns? > Sections 1.4.2& 2.5: the handling of "sms" in HTML forms references > "just as they are packaged when using a "mailto" URI, but the definition of > how > that happens is a feature of HTML and not of the URI scheme. > My recollection is that it isn't formally defined in the > W3C HTML specification, but it's also not in any (not obsolete) > IETF document. Same problem for web services. Perhaps those sections > should be marked as non-normative, and instead become informational -- > how the authors or their organizations intend to propose the > described changes to the appropriate standards bodies for the > relevant specifications. i have the same recollection as you, that there is no formal standard about this anywhere. how would be go about marking these as informal? is there a formal way of doing this, or just add a sentence at the beggining saying "the text of the following subsection is informal and for informational purposes only"? > I don't know why they need to specify section 3 at all -- every > web service SMS gateway could define its own mechanism for sending > SMS without making up funny URIs as a way of carrying the > destination information. Is this just an example? this section probably is a result of my personal frustration with how badly most clients handle unknown uri schemes, and that a more systematic way of doing this would be a good idea. would it be ok to leave it in there and mark it as informal as well? if not, i can remove it. > 4.4: of course it addresses a resource. That's why they're defining > a Resource Identifier. I'd just delete the first two sentences > and the "Instead, ". ok, done. thanks a lot and kind regards, dret. _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRnvA-0003PE-7A; Sun, 02 Sep 2007 07:47:16 -0400 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1IRAfa-0001lV-GH for apps-review-confirm+ok@megatron.ietf.org; Fri, 31 Aug 2007 13:52:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRAfa-0001kg-6K for APPS-REVIEW@ietf.org; Fri, 31 Aug 2007 13:52:34 -0400 Received: from chip2og56.obsmtp.com ([64.18.13.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IRAfY-0005Xt-W0 for APPS-REVIEW@ietf.org; Fri, 31 Aug 2007 13:52:34 -0400 Received: from source ([192.150.11.134]) by chip2ob56.postini.com ([64.18.5.12]) with SMTP; Fri, 31 Aug 2007 10:51:14 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l7VHnRIQ013129; Fri, 31 Aug 2007 10:49:27 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l7VHoxRC021859; Fri, 31 Aug 2007 10:50:59 -0700 (PDT) Received: from namail1.corp.adobe.com ([10.8.192.62]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Aug 2007 10:50:59 -0700 Received: from masinterlap06 ([10.7.240.21]) by namail1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Aug 2007 10:50:59 -0700 From: "Larry Masinter" To: "'Paul Hoffman'" , "'Lisa Dusseault'" , , "'Martin Duerst'" , References: <46D7579B.1020302@berkeley.edu> In-Reply-To: Date: Fri, 31 Aug 2007 10:50:58 -0700 Message-ID: <000001c7ebf7$7d342f90$779c8eb0$@org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acfr56fj4/1YNRm+Ryq5M8DM3mHVbAAC3Rmw Content-Language: en-us X-OriginalArrivalTime: 31 Aug 2007 17:50:59.0267 (UTC) FILETIME=[7D298130:01C7EBF7] X-Spam-Score: -3.3 (---) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-Mailman-Approved-At: Sun, 02 Sep 2007 07:47:15 -0400 Cc: antti.vaha-sipila@nokia.com, dret@berkeley.edu Subject: [APPS-REVIEW] RE: Fwd: SMS URI spec question X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org Is there a registry of pid-value, or is this it? Isn't it likely that most of the values will be unimplemented? I suppose it's harmless. I'm uncomfortable with the vague way in which "SMS messages can be concatenated to form longer messages" and the length limit, especially since you're expecting clients to dynamically generate sms messages for things like form submission. I think you either need to define the length limit and how it applies, or else define how, given a sms URI with a really long message body, how to turn it into a sequence of sms messages. Sections 1.4.2& 2.5: the handling of "sms" in HTML forms references "just as they are packaged when using a "mailto" URI, but the definition of how that happens is a feature of HTML and not of the URI scheme. My recollection is that it isn't formally defined in the W3C HTML specification, but it's also not in any (not obsolete) IETF document. Same problem for web services. Perhaps those sections should be marked as non-normative, and instead become informational -- how the authors or their organizations intend to propose the described changes to the appropriate standards bodies for the relevant specifications. I don't know why they need to specify section 3 at all -- every web service SMS gateway could define its own mechanism for sending SMS without making up funny URIs as a way of carrying the destination information. Is this just an example? 4.4: of course it addresses a resource. That's why they're defining a Resource Identifier. I'd just delete the first two sentences and the "Instead, ". Larry _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review