draft-saintandre-jabberid

Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imca1-0004b2-Ii; Mon, 29 Oct 2007 17:55:29 -0400 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1ImcZz-0004Zb-Nj for apps-review-confirm+ok@megatron.ietf.org; Mon, 29 Oct 2007 17:55:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImcZu-0004QJ-NJ for apps-review@ietf.org; Mon, 29 Oct 2007 17:55:22 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImcZu-0002GC-8j for apps-review@ietf.org; Mon, 29 Oct 2007 17:55:22 -0400 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l9TLspZ12982 for ; Mon, 29 Oct 2007 21:54:52 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 29 Oct 2007 17:54:42 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D123EE375@zcarhxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-saintandre-jabberid Thread-Index: Acgadk+HA+Y8nEe4Rw2Rkrk4WprNXA== From: "Glenn Parsons" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Subject: [APPS-REVIEW] draft-saintandre-jabberid 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: , Content-Type: multipart/mixed; boundary="===============1307300848==" Errors-To: apps-review-bounces@ietf.org This is a multi-part message in MIME format. --===============1307300848== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C81A76.5501A07A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C81A76.5501A07A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, By belated review of draft-saintandre-jabberid (which is simply a definition/registration of a jabber ID email header) is as follows - since this is 'jabber ID' informational is probably the right track. However, I don't know if the IESG will frown upon codifying a jabber ID since the more generic IM ID is mentioned and probably preferred....I probably would if I was on the IESG ;-)=20 - but because it will be an RFC, it should go in the permanent list and not the provisional list per the RFC 3864 guidelines=20 - XMPP-URI for the header encoding is I believe a problem, as it is different from the RFC2047 header encoding. Though one could argue that is for a different aspect. In that case it still appears to be different than the EAI work. I think mail clients will be able to decode one of these and not the XMPP-URI format.=20 - dealing with the multiple from address explanation is not suitable. Instead the jabber-ID shall be mapped to the sender header (which is one address) if the from header has more than one address.=20 Cheers, Glenn. ------_=_NextPart_001_01C81A76.5501A07A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-saintandre-jabberid

Folks,

By belated review of = draft-saintandre-jabberid (which is simply a definition/registration of = a jabber ID email header) is as follows

- since this is = 'jabber ID' informational is probably the right track. However, I don't = know if the IESG will frown upon codifying a jabber ID since the more = generic IM ID is mentioned and probably preferred....I probably would if = I was on the IESG ;-)

- but because it will = be an RFC, it should go in the permanent list and not the provisional = list per the RFC 3864 guidelines =

- XMPP-URI for the = header encoding is I believe a problem, as it is different from the = RFC2047 header encoding. Though one could argue that is for a different = aspect. In that case it still appears to be different than the EAI work. = I think mail clients will be able to decode one of these and not the = XMPP-URI format.

- dealing with the = multiple from address explanation is not suitable. Instead the jabber-ID = shall be mapped to the sender header (which is one address) if the from = header has more than one address.

Cheers,
Glenn.

------_=_NextPart_001_01C81A76.5501A07A-- --===============1307300848== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review --===============1307300848==-- Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiZCd-00055a-DU; Thu, 18 Oct 2007 13:30:35 -0400 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1IiZCb-00053o-KA for apps-review-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 13:30:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiZCL-0004jQ-Jm for apps-review@ietf.org; Thu, 18 Oct 2007 13:30:17 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IiZCL-00024u-0G for apps-review@ietf.org; Thu, 18 Oct 2007 13:30:17 -0400 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9IHUFlI011021; Thu, 18 Oct 2007 10:30:15 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9IHTnVt004252; Thu, 18 Oct 2007 10:30:13 -0700 Received: from 172.24.29.145 ([172.24.29.145]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Thu, 18 Oct 2007 17:30:11 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Thu, 18 Oct 2007 12:05:15 -0400 From: Eric Burger To: , Sam Hartman Message-ID: Thread-Topic: Review of draft-hartman-webauth-phishing-05 Thread-Index: AcgRoKuD6f5qA32TEdyH6AAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: Yves Lafon Subject: [APPS-REVIEW] Review of draft-hartman-webauth-phishing-05 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 Review of http://www.ietf.org/internet-drafts/draft-hartman-webauth-phishing-05.txt by Yves Lafon, forwarded on his behalf by Eric. If you wish to contact the reviewer directly, use the CC address above. In 1. Are single sign-on solutions taken into account ? Impersonation can happen and have bad effects (web mails, photo archives etc...) [seems to be handled in 3.2 and 4.1, might be good to introduce this earlier] In 3. "We assume that users have limited motivation to combat phishing." motivation ? Or just lack of knowledge to detect phishing attacks. removing this sentence will keep the meaning of the remaining of the paragrahp intact. In 3.1. "Mechanisms attackers use to accomplish this include links where the link name and URI target are misleading; email with links; DNS attacks; and on-path network attacks." what link name and URI target, the real ones (the URI bar) or the ones displayed by the User-Agent ? (like the bottom destination link bar) later in 3.1. "The attacker cannot replicate a UI that depends on information the attacker does not know. For example, an attacker could generally replicate the UI of a banking site's login page. However the attacker probably could not replicate the account summary page until the attacker learned the user name and password because the attacker would not know what accounts to list or approximate balances that will look convincing to a user. " does that mean that potentially sensitive information should be released _before_ authentication? It seems linked to paragraph 4.2 below, but the example given looks strange. In 4.1. The use of identity providers might help, but they will be subject to phishing attacks as well. What will be the impact on phishing if only a few identity providers services are subject to such attacks instead of lots of different sites? Faking an UI has a cost, and can lead to breach in far more services in that case. [4.7 addresses partially the issue] In 4.5. "1. Assuming that only certificates from trusted CAs are accepted..." Is this economically feasible ? It would assume that all sites using TLS should get a certificate from a trusted CA. In 8. How can a "secure web component" be... a secure web component as it is more and more easy to fake components and make them even look like "real" windows (in the case of auth popups). There is a contradiction between giving designers more graphical control to design web-based applications and the will to be able to expose secure components for authentication. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ 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 1IiUWT-0001h3-Bp; Thu, 18 Oct 2007 08:30:45 -0400 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1IiB7m-0006qM-NO for apps-review-confirm+ok@megatron.ietf.org; Wed, 17 Oct 2007 11:47:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiB7Y-00067a-CM for APPS-REVIEW@ietf.org; Wed, 17 Oct 2007 11:47:44 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IiB7X-0000eD-Kb for APPS-REVIEW@ietf.org; Wed, 17 Oct 2007 11:47:44 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l9HFlFbp008959; Wed, 17 Oct 2007 10:47:15 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l9HFlAj17749; Wed, 17 Oct 2007 10:47:15 -0500 (CDT) Message-ID: <47162E7E.2060302@alcatel-lucent.com> Date: Wed, 17 Oct 2007 10:47:10 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lisa Dusseault References: <87FC48F1-42C6-47A9-A97A-5966DAB12282@osafoundation.org> In-Reply-To: <87FC48F1-42C6-47A9-A97A-5966DAB12282@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab X-Mailman-Approved-At: Thu, 18 Oct 2007 08:30:44 -0400 Cc: APPS-REVIEW@ietf.org, GK@ninebynine.org, Jonathan Rosenberg , Henning Schulzrinne Subject: [APPS-REVIEW] Re: Review of SMS URI spec 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 Lisa Dusseault wrote: > Hi, > > I'd like to get reviews of the SMS URI spec that was submitted to me for > publication: > > http://www.ietf.org/internet-drafts/draft-wilde-sms-uri-13.txt > > You can always send review comments to the authors and to the IETF list, > but you can also just send comments to me if that's easiest. [...] Lisa: My review is below. Please forward to the author as appropriate. Overall, I am disposed to the IETF standardizing this. I believe there is sufficient interest in such a URI that if we (i.e., the IETF) do not fill the void, ad-hoc solutions will step in to do so. IMHO, one of the biggest point where the draft is silent is in its interaction with non-browser user agents (i.e., SIP user agents, or H.323 user agents, for example.) I do not know whether this sort of an interaction falls within the bounds of the draft, and I will let the APPS area and the authors decide if it does, but I do want to point it out. The draft, in S1.2.4, does an excellent job of showing how the sms URI scheme can be used by web browsers and email clients. But what happens when a SIP user agent is presented with a sms URI? It can do one of the following: 1) Convert it to a a tel URI and attempt to route it onwards using ENUM or other appropriate technology (although, certain parameters of the sms URI like "smsc" and "body" may not map well to a tel URI.) 2) Convert it to a tel URI, use ENUM to convert that to a sip URI, and THEN change the sms body to a SIP IM and deliver it to the SIP URI. 3) Access a web service, as depicted in S1.4.1, and allow subsequent interaction between the (human) user and the web service. 4) Present some sort of an error to the (human) user about not being able to support the sms URI (for example, if I try the sms URI -- sms:+16305551212 -- in Firefox, I get a dialog box saying "Firefox doesn't know how to open this address, because the protocol (sms) isn't associated with any program".) Since I suspect that dealing with SIP or H.323 intricacies is not part of this draft, it should probably have a blanket statement saying that non-browser (and non-email) user agents should behave as in (4) above when presented with the sms URI that they do not understand. One more important comment before moving on to the rest of the document is that in S3 (Security considerations), the easiest of security problems -- buffer overflow -- is not addressed. Having a simple sentence along the lines of "Implementations MUST ensure that the individual SMS messages are less than 140 octets. Implementations MUST also ensure that if message concatenation is being used, the number of segment messages sent does not overwhelm the receiver." (Note: I am not sure whether the last sentence can be realized in practice, so the authors are free to ignore it, or bid down the normative strength to a SHOULD.) The rest of my comments are: * S1.2.2: s/SMS messages MAY be submitted/SMS messages may be submitted * S1.2.3: The U in URI and URN stands for "Uniform", not "Universal." * S1.2.3, last paragraph: I would suggest taking out the phrase "...and it often is unclear how to separate these concepts." Clearly, people have tried to do so and there is enough literature around this: the authors provide a reference a couple of lines down, and in addition, S1.1.3 of rfc3986 also clarifies this. Maybe rewrite the last paragraph as something along these lines: OLD: URIs often are mentioned together with Universal Resource Names (URNs) and/or Uniform Resource Locators (URLs), and it often is unclear how to separate these concepts. For the purpose of this memo, only the term URI will be used, referring to the most fundamental concept. The World Wide Web Consortium (W3C) has issued a note [uri-clarification] discussing the topic of URIs, URNs, and URLs in detail. NEW: URIs often are mentioned together with Uniform Resource Names (URNs) and/or Uniform Resource Locators (URLs). For the purpose of this memo, only the term URI will be used, referring to the most fundamental concept (for a further clarification on the topic of differentiating a URI from a URN or a URL, please see [uri-clarification] and Section 1.1.3 of RFC 3986 [RFC3986].) * S1.2.4.2: I am more curious than anything else: do there exist web servers with SMS interfaces that get a HTML form over SMS? * S1.3.2: Coalesce the following paragraphs for readability: OLD: The syntax definition for "phonedigit" is taken from RFC 3966 [RFC3966]. The syntax definition for "query" is taken from RFC 3986 [RFC3986], please refer to that document. NEW: The syntax definition for "phonedigit" is taken from RFC 3966 [RFC3966]. The syntax definition for "query" is taken from RFC 3986 [RFC3986]; please refer to the individual document for the definition of these. * S1.3.5, last paragraph: Before the last sentence, probably insert a new one as follows: "In either case, the user agent MUST notify the user of this action." * The example in S1.4.1 would be better if it appears in S1.4 itself. It goes a long way in making the text of S1.4 understandable. I don't see a reason to have such a germane example in a different section. * Need IANA consideration section: ideally, S2 (URI Scheme Registration) would be part of an IANA consideration section. The text is all there, you just need to modify the section headings. * In S3, paragraphs 2,3,4 have nothing to do with security, as far as I can see. These are best put either in S1.2, or in a separate section of their own entitled "General considerations for SMS messages". HTH. Ciao. - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ 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 1Ihs02-0000fS-S1; Tue, 16 Oct 2007 15:22:42 -0400 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1Ihs01-0000cN-3j for apps-review-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 15:22:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihrzm-0000J6-Cy for APPS-REVIEW@ietf.org; Tue, 16 Oct 2007 15:22:26 -0400 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ihrzg-0001M0-6m for APPS-REVIEW@ietf.org; Tue, 16 Oct 2007 15:22:26 -0400 Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8C08314220A; Tue, 16 Oct 2007 12:22:14 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0tnC-xdt87cT; Tue, 16 Oct 2007 12:22:06 -0700 (PDT) Received: from [10.1.4.107] (ip20.commerce.net [157.22.41.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 5627814220D; Tue, 16 Oct 2007 12:22:06 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <87FC48F1-42C6-47A9-A97A-5966DAB12282@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Date: Tue, 16 Oct 2007 12:22:03 -0700 To: Henning Schulzrinne , "Vijay K. Gurbani" , Graham Klyne X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -4.0 (----) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Jonathan Rosenberg , APPS-REVIEW@ietf.org Subject: [APPS-REVIEW] Review of SMS URI spec 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, I'd like to get reviews of the SMS URI spec that was submitted to me for publication: http://www.ietf.org/internet-drafts/draft-wilde-sms-uri-13.txt You can always send review comments to the authors and to the IETF list, but you can also just send comments to me if that's easiest. I'm always interested in opinions on the disposition of the document (should the IETF standardize it on the standards track) as well as the suitability of the features and syntax. There have been some other reviews and fair interest in implementing for an individual submission. BTW Jonathan recommended Henning and Vijay specifically for getting IPTel expertise in the reviews; Graham is the expert reviewer for URIs. I just noticed that this document doesn't have an IANA section which is surely a problem. Last Call ends Nov 8 and I intend to get the authors to do another revision then; of course I will still want to hear of serious issues if they're discovered after that, but before would really be better :) Thanks, Lisa _______________________________________________ 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 1IfI8X-0001Uh-Kk; Tue, 09 Oct 2007 12:40:49 -0400 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1IfI8W-0001UZ-Iz for apps-review-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 12:40:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfI8W-0001U4-89; Tue, 09 Oct 2007 12:40:48 -0400 Received: from robin.verisign.com ([65.205.251.75]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfI8M-0007Rd-LV; Tue, 09 Oct 2007 12:40:39 -0400 Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id l99Gbnam023444; Tue, 9 Oct 2007 09:37:49 -0700 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Oct 2007 09:40:31 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [KEYPROV] Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP Date: Tue, 9 Oct 2007 09:37:08 -0700 Message-ID: <2788466ED3E31C418E9ACC5C31661557053728@mou1wnexmb09.vcorp.ad.vrsn.com> In-Reply-To: <470BA265.4000709@gmx.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [KEYPROV] Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP Thread-Index: AcgKi55+PKWSazh0TrWMvBA+MAjBJAABRSoQ From: "Hallam-Baker, Phillip" To: "Julian Reschke" X-OriginalArrivalTime: 09 Oct 2007 16:40:31.0207 (UTC) FILETIME=[1B26FF70:01C80A93] X-Spam-Score: -4.0 (----) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: keyprov@ietf.org, Hannes Tschofenig , Chris.Newman@Sun.COM, 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 don't see what you mean by 'originally intended'. Back in 1992 I was looking at the use of HTTP to control a physics = experiment. The idea that the Web was simply a publication tool had not = yet taken hold. At the time we had less than 100 Web users. So I think = it counts as original intent. >From a security point of view I am much more interested in improving the = security of the Internet, rather than an Internet architecture that is = likely to be ignored as impractical. If we tell people not to use port 80 they will simply ignore us and use = port 80 anyway. When Java first appeared on the Web I tried to persuade = Gosling that Java content should be tagged application/java and not try = to bypass content firewalls by tagging itself application/data. He = ignored me even though it would have cost nothing to make the change at = that point. If on the other hand we give people a mechanism that they can use and = which provides them with real benefits over raw port 80 we can persuade = them down that route. A platform designer is not going to prevent Web = Services being deployed on port 80 no matter what the IAB says. But a = platform designer could possibly be persuaded to implement a Web Service = connect call that employed the SRV mechanism by default, thus taking = advantage of the load sharing capabilities it offers. > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de]=20 > Sent: Tuesday, October 09, 2007 11:47 AM > To: Hallam-Baker, Phillip > Cc: Chris.Newman@Sun.COM; Hannes Tschofenig;=20 > apps-REVIEW@ietf.org; keyprov@ietf.org > Subject: Re: [KEYPROV] Re: [APPS-REVIEW] Review of HTTP=20 > Binding for DSKPP >=20 > Hallam-Baker, Phillip wrote: > > ... > >> However, I will observe that the IETF WebDAV family of=20 > protocols has=20 > >> gone in a quite different direction from the SOAP over HTTP web=20 > >> services protocols. So our use of port 80 is already not in sync=20 > >> with the rest of the web services world. > >=20 > > WebDav started a long time ago, well before anyone was=20 > talking about SOAP or Web Services as a stack. > > ... >=20 > I guess part of the problem is to distinguish between protocols that > *use* HTTP the way it was designed to be used (auch as WebDAV or > AtomPub) from protocols that just use HTTP as a transport=20 > layer (SOAP & friends). >=20 > Both WebDAV and AtomPub both use HTTP to edit/author HTTP resources.=20 > IMHO there's no point in running these operations on a=20 > different port from the one the resulting resources can be=20 > retrieved from. >=20 > Best regards, Julian >=20 _______________________________________________ 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 1IfHIg-0001Bm-D4; Tue, 09 Oct 2007 11:47:14 -0400 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1IfHIf-00015d-2I for apps-review-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 11:47:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfHIe-00015B-Ov for apps-REVIEW@ietf.org; Tue, 09 Oct 2007 11:47:12 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IfHIZ-0003Gt-7M for apps-REVIEW@ietf.org; Tue, 09 Oct 2007 11:47:12 -0400 Received: (qmail invoked by alias); 09 Oct 2007 15:46:50 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.87]) [217.91.35.233] by mail.gmx.net (mp026) with SMTP; 09 Oct 2007 17:46:50 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19Fp8k20dRFux/elDj4DXV633STqSXLLgqV+4RM5t CcrvmKx+zPqydc Message-ID: <470BA265.4000709@gmx.de> Date: Tue, 09 Oct 2007 17:46:45 +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: "Hallam-Baker, Phillip" Subject: Re: [KEYPROV] Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP References: <2788466ED3E31C418E9ACC5C3166155705370D@mou1wnexmb09.vcorp.ad.vrsn.com> In-Reply-To: <2788466ED3E31C418E9ACC5C3166155705370D@mou1wnexmb09.vcorp.ad.vrsn.com> 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: 79899194edc4f33a41f49410777972f8 Cc: keyprov@ietf.org, Hannes Tschofenig , Chris.Newman@Sun.COM, 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 Hallam-Baker, Phillip wrote: > ... >> However, I will observe that the IETF WebDAV family of >> protocols has gone in a quite different direction from the >> SOAP over HTTP web services protocols. So our use of port 80 >> is already not in sync with the rest of the web services world. > > WebDav started a long time ago, well before anyone was talking about SOAP or Web Services as a stack. > ... I guess part of the problem is to distinguish between protocols that *use* HTTP the way it was designed to be used (auch as WebDAV or AtomPub) from protocols that just use HTTP as a transport layer (SOAP & friends). Both WebDAV and AtomPub both use HTTP to edit/author HTTP resources. IMHO there's no point in running these operations on a different port from the one the resulting resources can be retrieved from. 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 1IfGTe-0000XL-Ts; Tue, 09 Oct 2007 10:54:30 -0400 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1IfGTe-0000X5-2o for apps-review-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 10:54:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfGTd-0000Up-PW for apps-REVIEW@ietf.org; Tue, 09 Oct 2007 10:54:29 -0400 Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfGTO-0002Dp-Oi for apps-REVIEW@ietf.org; Tue, 09 Oct 2007 10:54:21 -0400 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id l99EoVKR019814; Tue, 9 Oct 2007 07:50:32 -0700 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Oct 2007 15:53:41 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [KEYPROV] Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP Date: Tue, 9 Oct 2007 07:50:19 -0700 Message-ID: <2788466ED3E31C418E9ACC5C31661557053712@mou1wnexmb09.vcorp.ad.vrsn.com> In-Reply-To: <0DF4D80F-8D53-4C59-A7C5-376AB837595B@yahoo-inc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [KEYPROV] Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP Thread-Index: AcgKQI357b/k1rtdRw2+1lN3BxhTTwAQagaA From: "Hallam-Baker, Phillip" To: "Mark Nottingham" X-OriginalArrivalTime: 09 Oct 2007 14:53:41.0904 (UTC) FILETIME=[2EE8F900:01C80A84] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Hannes Tschofenig , 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 > From: Mark Nottingham [mailto:mnot@yahoo-inc.com]=20 > Without speaking to BCP56, a few things here caught my eye... >=20 > On 2007/10/05, at 5:11 AM, Hallam-Baker, Phillip wrote: > > It is not helpful here if the IETF is going to insist on a separate=20 > > definition of Web Services specifications that is not in sync with=20 > > where the Web Services world is. >=20 > I'm sure both the W3C and OASIS would love it if the locus of=20 > the "Web Services world" could be nailed down, never mind the IETF. Yes, there is certainly an element of the old VMS manual problem. If you = remember the days of the grey wall, there were 50 or so binders which = each described one aspect of the VMS architecture in mind numbing = detail. Most people simply gave up. If you looked long enough you might have come across a volume called the = VMS software architecture which was the key to the whole manual set. The = architecture manual explained all the things you needed to know like how = DCL worked, how AST completions worked and the like. Unless you happened = to strike lucky and find that manual there was simply too much to = absorb. Web Services is worse because there isn't a manual. > > Either the BCP56 view is right in which case we need the=20 > proponents of=20 > > this view to be talking to the wider Web Services world (OASIS, > > W3C) and arriving at a consensus position or the BCP56 view is=20 > > obsolete and needs to be updated. >=20 > The W3C, for one, has a very clear position about the=20 > relationship between the Web and Web Services, which includes=20 > use of HTTP; see documents by the TAG, for example. The IETF needs to be saying the same thing, not something different. > > The port number issue is somewhat more complex. The number of Web=20 > > Services is rapidly expanding and the idea of one port per=20 > Web Service=20 > > is simply not sustainable. We only have 65536 ports and we=20 > are going=20 > > to have far more Web Services in use. >=20 > If you expand "Web Services" to include what some people are=20 > now calling "HTTP Web Services" or "RESTful Web Services," I=20 > agree that > BCP56 needs some clarification. Well I don't use the term RESTfull because I don't think those following = it are really follwing Fielding's architecture so much as they are doing = Web Services over raw HTTP rather than with SOAP. That is also fine and in fact that is why I think discussion of Web = Services should begin with WSDL rather than with SOAP. You can do a Web = Service with or without SOAP and you can do a Web Service with or = without XML schema. But if you end up with something that you can't = describe in WSDL it probably isn't a Web Service. _______________________________________________ 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 1IfGIx-0002mR-IA; Tue, 09 Oct 2007 10:43:27 -0400 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1IfGIw-0002k6-FV for apps-review-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 10:43:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfGIv-0002SC-CN; Tue, 09 Oct 2007 10:43:25 -0400 Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfGIi-0001x5-9j; Tue, 09 Oct 2007 10:43:18 -0400 Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id l99EdcJm018899; Tue, 9 Oct 2007 07:39:38 -0700 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Oct 2007 07:42:20 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [KEYPROV] Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP Date: Tue, 9 Oct 2007 07:38:51 -0700 Message-ID: <2788466ED3E31C418E9ACC5C3166155705370D@mou1wnexmb09.vcorp.ad.vrsn.com> In-Reply-To: <9779E47D06A3D56F44788D7F@446E7922C82D299DB29D899F> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [KEYPROV] Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP Thread-Index: AcgKNhJIKk3gUfBfSca4tXjYFQQvvwARMOZQ From: "Hallam-Baker, Phillip" To: , "Hannes Tschofenig" , X-OriginalArrivalTime: 09 Oct 2007 14:42:20.0576 (UTC) FILETIME=[98CE9200:01C80A82] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: keyprov@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 > From: Chris.Newman@Sun.COM [mailto:Chris.Newman@Sun.COM]=20 > > It is not helpful here if the IETF is going to insist on a separate=20 > > definition of Web Services specifications that is not in sync with=20 > > where the Web Services world is. >=20 > When protocols are built using OASIS or W3C protocols such as=20 > services layered on SOAP over HTTP, then we're entering an=20 > area where the IETF lacks expertise.=20 > One of the litmus tests for such work is that it has rough=20 > consensus both within the IETF and with the other standards=20 > organizations. Hence my proposal that the resolution here be that the IAB and apps area = talk to the W3C TAG and OASIS TAB. What the resolution is matters a = whole heap less than that we either agree on a common resolution or note = that there are differences. > However, I will observe that the IETF WebDAV family of=20 > protocols has gone in a quite different direction from the=20 > SOAP over HTTP web services protocols. So our use of port 80=20 > is already not in sync with the rest of the web services world. WebDav started a long time ago, well before anyone was talking about = SOAP or Web Services as a stack. In the meantime the IETF has made a number of unfortunate choices, not = least the attempt to prempt the W3C/OASIS work by racing BEEP to DRAFT = standard despite the fact that it has virtually no platform support. > > In either case this is an issue that the IAB needs to=20 > address. BCP56=20 > > is their work product, I believe. They need to be maintaining it. >=20 > I'm not sure the IAB has the correct composition of=20 > individuals to address these concerns, particularly in the=20 > area of web services and web protocols. It might be better=20 > if a revision to BCP 56 was driven by individuals with the=20 > appropriate expertise working with the IAB as necessary. If the IAB lacks the necessary individuals then ask NOMCON to fix this. = The requirement here is for a group of people who are capable of talking = to and evaluating input from people who are experts in Web Services, not = to be experts themselves.=20 > > In particular the idea that WSDL is somehow dispensible as=20 > a component=20 > > in the Web Services architecture is not a widely held=20 > position within=20 > > the Web Services world. >=20 > As an area director, I will not require WSDL until there is=20 > community consensus within the IETF that it should be=20 > required. We already have far too many bars to jump over to=20 > get standards approved and I'm not inclined to add new ones=20 > absent evidence of substantial value. The message was=20 > forwarded somewhat out of context -- I was asked if I would=20 > require a WSDL profile and I answered that question. If I=20 > were asked the question "should a W3C/OASIS standards based=20 > web service have a WSDL profile?", my answer would be "ask=20 > the W3C/OASIS communities". I was pushing back against the impression you created. The advice I would give to anyone writing a Web Service is that they = should use WSDL because it will help them write the specification and = help developers implement it.=20 WSDL is not like writing a MIB, thinking about it as a profile is = unhelpful. WSDL is a formal description of your protocol. It's a tool = that you should think about in the same way that you would think about = EBNF or such. You would not talk about an EBNF profile of RFC822 and its = not helpful to talk about a WSDL profile of a Web Service. > > We already have a technology that meets this need - the SRV record.=20 > > Unlike some recent DNS records there is absoluely no problem with=20 > > support for SRV record deployment. Practically all the DNS=20 > servers in=20 > > service, including Windows support SRV. > > > > Rather than registering a port for the KEYPROV protocol we should=20 > > instead define an SRV prefix. Wildcarding issues are not=20 > relevant in=20 > > this particular case. >=20 > I find this proposal very interesting. To me, the underlying=20 > value of separate ports is the benefit of architectural=20 > separation of components (security, software design,=20 > multi-vendor interoperability, etc). If the community=20 > chooses an alternative mechanism to provide that value, I=20 > suspect that would address the underlying motivation of the=20 > discussion in BCP 56 about separate ports. The problem with BCP 56 is that it is written to the assumption that the = Internet will look pretty much the same in twenty years time as it does = today. I think we have to at least have a contingency plan to deal with = an Internet with a million protocols in active use. The killer apps of the Internet today are almost exclusively = human-machine protocols. We have almost no layer 7 protocols that are = machine-machine.=20 Humans have a limited number of needs and will tolerate a limited number = of interaction modes. Over time the number of active killer = human-machine protocols is unlikely to grow beyond 5 or so. The need to = educate the human keeps complexity under control.=20 That constraint goes away when machine-machine protocols are concerned. = There are a dozen or more protocols in use just for card payment = services. There is some consolidation but nothing like the consolidation = we see in the human interaction space. It simply does not matter as much = if EBay does or does not use the same payment protocol as Zix = corporation. If a standards based service is introduced it will be in = addition to the proprietary offerings and displacement will be slow. I do see standardization pressures on Web Services themselves, as = distinct from the platform. But unlike the human-machine space where = standardization is motivated by the need for interoperation I see = standards in the Web Services application world being driven by the need = to reduce complexity in order to enable new development. The demand to = standardize card acquisiton protocols is going to come from some new = requirement (e.g. need to support EMV) that hits all the established = operators, not standards for the sake of it. When VeriSign took over = Cybercash we kept the old cybercash protocols alongside Payflow. So fast forward a few decades and I think that the number of Web = Services in use will have grown exponentially. That is a bad match for = an architecture that requires a fixed resource be consumed per protocol. The constraints I see here are 1) Need to support a very large number of Web Services (millions) 2) Need to provide a protocol description that can be easily read by a = firewall Port numbers meet the second need but not the first. SOAP firewalls meet = the first but not the second. SOAP is expressly designed to expose the = necessary information to a SOAP aware firewall but it is vastly more = complex than port filtering. SOAP aware firewalls will certainly have a place but I see them as = something you would use to perform a second pass after you have made a = basic go/nogo decision. Pushing this to the naming layer makes sense to me.=20 _______________________________________________ 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 1If8ux-0002r6-Is; Tue, 09 Oct 2007 02:50:11 -0400 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1If8uw-0002qB-Rh for apps-review-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 02:50:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1If8us-0002Pt-4h for apps-REVIEW@ietf.org; Tue, 09 Oct 2007 02:50:06 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1If8uL-0006ge-Iw for apps-REVIEW@ietf.org; Tue, 09 Oct 2007 02:49:33 -0400 Received: from [127.0.0.1] (socks1.corp.yahoo.com [216.145.54.158]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.8/y.rout) with ESMTP id l996nIMj005467 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 8 Oct 2007 23:49:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=in-reply-to:references:mime-version:content-type:message-id:cc: content-transfer-encoding:from:subject:date:to:x-mailer; b=X+lz9hiNgEqS0PPVYvYPvkXN518PpfxT6CjbTZ2yMSWNgVy2IdJHByp+i0KNRDNP In-Reply-To: <2788466ED3E31C418E9ACC5C31661557053526@mou1wnexmb09.vcorp.ad.vrsn.com> References: <2788466ED3E31C418E9ACC5C31661557053526@mou1wnexmb09.vcorp.ad.vrsn.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0DF4D80F-8D53-4C59-A7C5-376AB837595B@yahoo-inc.com> Content-Transfer-Encoding: 7bit From: Mark Nottingham Subject: Re: [KEYPROV] Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP Date: Tue, 9 Oct 2007 16:47:31 +1000 To: "Hallam-Baker, Phillip" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Hannes Tschofenig , 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 Without speaking to BCP56, a few things here caught my eye... On 2007/10/05, at 5:11 AM, Hallam-Baker, Phillip wrote: > > Web Services is a standards based architecture with broad industry- > wide support. Keith's RFC was written in 2002 before the Web > Services architecture was developed. There is clearly a conflict > between the views being advance here and established practice for > the design and implementation of Web Services based specifications. It would be interesting to see these claims supported -- e.g., references for these standards, their architecture and evidence of broad support for those standards and that architecture. > It is not helpful here if the IETF is going to insist on a separate > definition of Web Services specifications that is not in sync with > where the Web Services world is. I'm sure both the W3C and OASIS would love it if the locus of the "Web Services world" could be nailed down, never mind the IETF. > Either the BCP56 view is right in which case we need the proponents > of this view to be talking to the wider Web Services world (OASIS, > W3C) and arriving at a consensus position or the BCP56 view is > obsolete and needs to be updated. The W3C, for one, has a very clear position about the relationship between the Web and Web Services, which includes use of HTTP; see documents by the TAG, for example. > The port number issue is somewhat more complex. The number of Web > Services is rapidly expanding and the idea of one port per Web > Service is simply not sustainable. We only have 65536 ports and we > are going to have far more Web Services in use. If you expand "Web Services" to include what some people are now calling "HTTP Web Services" or "RESTful Web Services," I agree that BCP56 needs some clarification. Cheers, -- Mark Nottingham mnot@yahoo-inc.com _______________________________________________ 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 1If7k4-0007tH-Ac; Tue, 09 Oct 2007 01:34:52 -0400 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1If7k2-0007s0-Gf for apps-review-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 01:34:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1If7jx-0007na-Nd; Tue, 09 Oct 2007 01:34:45 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1If7jr-00011g-AD; Tue, 09 Oct 2007 01:34:45 -0400 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l995YMKp020089; Tue, 9 Oct 2007 05:34:22 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 <0JPM00C01Q32JO00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM); Mon, 08 Oct 2007 23:34:22 -0600 (MDT) Received: from [10.0.1.3] (24-205-138-209.dhcp.psdn.ca.charter.com [24.205.138.209]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JPM00GCAQ4ZWB10@mail-amer.sun.com>; Mon, 08 Oct 2007 23:34:22 -0600 (MDT) Date: Fri, 05 Oct 2007 10:20:01 -0700 From: Chris Newman Subject: RE: [KEYPROV] Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP In-reply-to: <2788466ED3E31C418E9ACC5C31661557053526@mou1wnexmb09.vcorp.ad.vrsn.com> To: "Hallam-Baker, Phillip" , Hannes Tschofenig , apps-REVIEW@ietf.org Message-id: <9779E47D06A3D56F44788D7F@446E7922C82D299DB29D899F> 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: <2788466ED3E31C418E9ACC5C31661557053526@mou1wnexmb09.vcorp.ad.vrsn.c om> X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: keyprov@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 Hallam-Baker, Phillip wrote on 10/4/07 12:11 -0700: > > > This is a very troubling statement in my view. I also find the situation troubling and welcome debate on the topic. > Web Services is a standards based architecture with broad industry-wide > support. Keith's RFC was written in 2002 before the Web Services architecture > was developed. There is clearly a conflict between the views being advance > here and established practice for the design and implementation of Web > Services based specifications. > > It is not helpful here if the IETF is going to insist on a separate > definition of Web Services specifications that is not in sync with where the > Web Services world is. When protocols are built using OASIS or W3C protocols such as services layered on SOAP over HTTP, then we're entering an area where the IETF lacks expertise. One of the litmus tests for such work is that it has rough consensus both within the IETF and with the other standards organizations. However, I will observe that the IETF WebDAV family of protocols has gone in a quite different direction from the SOAP over HTTP web services protocols. So our use of port 80 is already not in sync with the rest of the web services world. > Either the BCP56 view is right in which case we need the proponents of this > view to be talking to the wider Web Services world (OASIS, W3C) and arriving > at a consensus position or the BCP56 view is obsolete and needs to be updated. I suspect reality lies somewhere in the middle. > In either case this is an issue that the IAB needs to address. BCP56 is their > work product, I believe. They need to be maintaining it. I'm not sure the IAB has the correct composition of individuals to address these concerns, particularly in the area of web services and web protocols. It might be better if a revision to BCP 56 was driven by individuals with the appropriate expertise working with the IAB as necessary. > In particular the idea that WSDL is somehow dispensible as a component in the > Web Services architecture is not a widely held position within the Web > Services world. As an area director, I will not require WSDL until there is community consensus within the IETF that it should be required. We already have far too many bars to jump over to get standards approved and I'm not inclined to add new ones absent evidence of substantial value. The message was forwarded somewhat out of context -- I was asked if I would require a WSDL profile and I answered that question. If I were asked the question "should a W3C/OASIS standards based web service have a WSDL profile?", my answer would be "ask the W3C/OASIS communities". > The port number issue is somewhat more complex. The number of Web Services is > rapidly expanding and the idea of one port per Web Service is simply not > sustainable. We only have 65536 ports and we are going to have far more Web > Services in use. > > We already have a technology that meets this need - the SRV record. Unlike > some recent DNS records there is absoluely no problem with support for SRV > record deployment. Practically all the DNS servers in service, including > Windows support SRV. > > Rather than registering a port for the KEYPROV protocol we should instead > define an SRV prefix. Wildcarding issues are not relevant in this particular > case. I find this proposal very interesting. To me, the underlying value of separate ports is the benefit of architectural separation of components (security, software design, multi-vendor interoperability, etc). If the community chooses an alternative mechanism to provide that value, I suspect that would address the underlying motivation of the discussion in BCP 56 about separate ports. - Chris _______________________________________________ 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 1Idubg-000736-Go; Fri, 05 Oct 2007 17:21:12 -0400 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1IdWAo-0007Nb-5z for apps-review-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 15:15:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdWAj-00073m-J8; Thu, 04 Oct 2007 15:15:45 -0400 Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdWAZ-0004RD-5z; Thu, 04 Oct 2007 15:15:41 -0400 Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id l94JC1iJ023691; Thu, 4 Oct 2007 12:12:01 -0700 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Oct 2007 12:14:59 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [KEYPROV] Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP Date: Thu, 4 Oct 2007 12:11:40 -0700 Message-ID: <2788466ED3E31C418E9ACC5C31661557053526@mou1wnexmb09.vcorp.ad.vrsn.com> In-Reply-To: <69CC0AC5EB46F7B9D4CE3495@[10.1.110.5]> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [KEYPROV] Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP Thread-Index: AcgGp13nekPs9RdISR6c88HIxUW1FgAAXm9A From: "Hallam-Baker, Phillip" To: "Chris Newman" , "Hannes Tschofenig" , X-OriginalArrivalTime: 04 Oct 2007 19:14:59.0335 (UTC) FILETIME=[DB525970:01C806BA] X-Spam-Score: 0.0 (/) X-Scan-Signature: cbb41f2dbf0f142369614756642005e3 X-Mailman-Approved-At: Fri, 05 Oct 2007 17:21:11 -0400 Cc: keyprov@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 This is a very troubling statement in my view. Web Services is a standards based architecture with broad industry-wide = support. Keith's RFC was written in 2002 before the Web Services = architecture was developed. There is clearly a conflict between the = views being advance here and established practice for the design and = implementation of Web Services based specifications. It is not helpful here if the IETF is going to insist on a separate = definition of Web Services specifications that is not in sync with where = the Web Services world is. Either the BCP56 view is right in which case we need the proponents of = this view to be talking to the wider Web Services world (OASIS, W3C) and = arriving at a consensus position or the BCP56 view is obsolete and needs = to be updated. In either case this is an issue that the IAB needs to address. BCP56 is = their work product, I believe. They need to be maintaining it. In particular the idea that WSDL is somehow dispensible as a component = in the Web Services architecture is not a widely held position within = the Web Services world.=20 The port number issue is somewhat more complex. The number of Web = Services is rapidly expanding and the idea of one port per Web Service = is simply not sustainable. We only have 65536 ports and we are going to = have far more Web Services in use.=20 We already have a technology that meets this need - the SRV record. = Unlike some recent DNS records there is absoluely no problem with = support for SRV record deployment. Practically all the DNS servers in = service, including Windows support SRV.=20 Rather than registering a port for the KEYPROV protocol we should = instead define an SRV prefix. Wildcarding issues are not relevant in = this particular case. The firewall issues are pretty complex, far more complex than BCP56 = allows. In particular the design of SOAP and WS-* is largely motivated = by precisely the observation that port filtering is no longer a very = effective firewall strategy. That's why the original SOAP architecture = envisioned XML firewalls, UDDI and the like to route SOAP messages. I don't think that either port filtering or SOAP firewalls is a viable = near term strategy. Implementing a SOAP firewall is just too big an = increase in complexity over traditional port filtering for it to be seen = as a successor. SRV filtering on the other hand offers essentially the = same degree of complexity. > -----Original Message----- > From: Chris Newman [mailto:Chris.Newman@Sun.COM]=20 > Sent: Tuesday, October 02, 2007 9:47 PM > To: Hannes Tschofenig; apps-REVIEW@ietf.org > Cc: keyprov@ietf.org > Subject: [KEYPROV] Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP >=20 > Hannes Tschofenig wrote on 9/30/07 12:19 +0200: > > thank you Chris for the pointer to RFC 3205 (BCP 56). I now read it=20 > > and it is indeed a very interesting document. Too bad that I didn't=20 > > came across it earlier. > > Reading through that document I got the impression that the=20 > > suggestions that can be found in there are not exercised by=20 > today's protocol designs. >=20 > I largely support BCP 56 and as an IESG member I consider it=20 > my duty and within my authority to enforce that BCP using my=20 > best judgment. However, some of the advice it gives could be=20 > updated to make it better and it could use advice in=20 > additional areas -- I would support an effort to revise it,=20 > although the present HTTP WG proposal may not be the right=20 > place to do that work. I'm uncomfortable when my best=20 > technical judgment disagrees with common practice and am=20 > unlikely to use my IESG authority to permanently block=20 > forward progress on a document in that case. However, when=20 > I'm aware of a BCP rule and agree with it, I consider it my=20 > duty at a minimum to verify the community considered the rule=20 > and had explicit community rough consensus to violate it. >=20 > > (c) New port number for DSKPP since the usage is so different from=20 > > ordinary HTTP webbrowsing (This is quite controversal when=20 > it comes to=20 > > firewall traversal and might require more discussions. See > >=20 > http://www1.ietf.org/mail-archive/web/apps-review/current/msg00090.htm > > l) > > > > None of the protocols I have been working on defines a new=20 > port. Can=20 > > you give a reference to a recently developed protocol that=20 > carries XML=20 > > on top of HTTP that uses a new port number? >=20 > I'll give two examples of HTTP-based protocols with separate=20 > ports where that was clearly the right technical choice in my opinion: > IPP: RFC 2910 > SIP: RFC 3261 >=20 > I'll also mention that the Mail Submission protocol runs on=20 > port 587 primarily, but can also run on port 25. That's a=20 > practical way to (1) remain backwards compatible with=20 > deployed usage or limitations. (2) provide a separate port=20 > when it's helpful to avoid middle-box restrictions on an=20 > overused/abused port like port 25. >=20 > It's my technical opinion there should be a separate port=20 > registered for HTTP access to information used to validate=20 > security credentials (CRLs, OCSP, etc) with port 80 as a=20 > fallback for situations where the separate port can't be used=20 > and for legacy use. It's plausible to build an Internet=20 > service where port 80 was intercepted by default for the=20 > authentication screen, but this other port was (partially)=20 > open so a client can get security information necessary to=20 > verify the interception HTTP server's credentials. I think=20 > that would be a better architecture than running everything=20 > over port 80 and forcing the port 80 application-level=20 > middle-boxes to become ever more sophisticated and failure prone. >=20 > I have voted DISCUSS for discussion on this topic with=20 > document authors, but I have not yet blocked forward progress=20 > on any documents on this basis. >=20 > > (d) New URI scheme > > (Currently we use the HTTP/HTTPS schemes but that does not=20 > seem to be=20 > > inline with the recommendations in BCP 56.) > > > > Neither HELD, SCVP, LoST nor DSKPP define a new URI scheme.=20 > In LoST we=20 > > had a URL registration in the document once, see Section 16.5 of=20 > > draft-ietf-ecrit-lost-03, but removed it later (co-author of that=20 > > document is Ted Hardie, the former Applications Area Director). >=20 > For things that only run on port 80, I generally wouldn't=20 > expect a separate URL scheme. >=20 > > (e) WSDL Usage: Lisa and Chris do not see WSDL as something being=20 > > useful. In fact, I haven't found a person who argued in=20 > favor of WSDL.=20 > > Hence, I believe we should avoid it. >=20 > To be precise: I have not yet seen any evidence that WSDL is=20 > useful. However, I have not educated myself on the protocol=20 > sufficiently to have formed an opinion on whether or not it is useful. >=20 > > (f) Error Codes: RFC 3205 points to the problems of defining error=20 > > codes when applications are layered on top of HTTP. The=20 > suggestion is=20 > > to essentially only use 200 (for complete success) and 500 (for=20 > > complete failure) at the HTTP layer and to use=20 > "application" specific=20 > > error codes inside the layer application itself. We are essentially=20 > > doing this. The only other error message that is being mentioned is=20 > > 403 and since it is independent of the DSKPP protocol=20 > interaction it should be fine as well. > > > > (g) HTTP client, proxy and server code: We added text regarding the=20 > > expected behavior of clients, proxies and server in Section 5 of=20 > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-keyprov-dskpp-0 0.txt. I=20 > > guess we are doing fine there. > > > > I am OK with (a), (b), (e), (f) and (g). I am not sure=20 > about (c) and (d). > > Help needed. > > > > Ciao > > Hannes > > > > PS: Regarding Mime-Types: > > > > In KEYPROV with the DSKPP document we should use=20 > application/dskpp+xml=20 > > instead of application/vnd.ietf.keyprov.dskpp+xml > > > > The IANA registry for the MIME type should look similar to=20 > the one in=20 > > Section > > 17.2 of draft-ietf-ecrit-lost-06. > > > > We also need to add a registry for the schema and the=20 > namespace (see=20 > > Section > > 11.1 of draft-ietf-geopriv-http-location-delivery-02.txt=20 > for the URN=20 > > sub-namespace registration, and Section 11.2 of for the XML schema=20 > > 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=20 > browser, I would=20 > >> strongly encourage registering a separate port. In the=20 > SMTP world,=20 > >> the primary source of interoperability problems is=20 > application-level=20 > >> gateways/firewalls. At this point it's inevitable we'll=20 > end up with=20 > >> intrusive firewalls on port 80 that will break anything=20 > beyond stock=20 > >> browser-based HTTP. I encourage new HTTP-based protocols=20 > to register=20 > >> a separate port so they have the opportunity to avoid such=20 > damage and=20 > >> interoperability problems. It also simplifies responsible=20 > firewall=20 > >> operation by enabling port-based service restrictions that=20 > are more=20 > >> scalable and less intrusive. > >> > >> I have yet to see any evidence that WSDL is useful in practice but=20 > >> that may be due to my lack of experience with web services. > >> > >> I find Relax NG and/or XML schema useful for XML-based=20 > >> protocols/formats whether or not they are built on top of=20 > HTTP. My=20 > >> understanding is that Relax NG is better for extensible=20 > entity-based=20 > >> XML formats, whereas XML Schema is better for XML formats=20 > with strong=20 > >> 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=20 > >>> described in > >>> DSKPP: > >>>=20 > http://www.ietf.org/internet-drafts/draft-ietf-keyprov-dskpp-00.txt > >>> > >>> I went through a couple of documents that describe an=20 > HTTP binding=20 > >>> and noticed all of them are slightly different. If you,=20 > for example,=20 > >>> take a look at another recent work, namely HELD, from the GEOPRIV=20 > >>> working group then you will notice that the author incorporated a=20 > >>> WSDL binding. The draft is > >>> here: > >>>=20 > http://www.ietf.org/internet-drafts/draft-ietf-geopriv-http-location > >>> -delive > >>> ry > >>> > >>> -01.txt > >>> > >>> Do people on this list have an opinion about the content=20 > they would=20 > >>> 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 > > >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > KEYPROV mailing list > KEYPROV@ietf.org > https://www1.ietf.org/mailman/listinfo/keyprov >=20 _______________________________________________ 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 1IctK3-0003td-Sr; Tue, 02 Oct 2007 21:46:47 -0400 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1IctK2-0003tT-Kh for apps-review-confirm+ok@megatron.ietf.org; Tue, 02 Oct 2007 21:46:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IctK2-0003o0-7R; Tue, 02 Oct 2007 21:46:46 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IctJp-00071U-20; Tue, 02 Oct 2007 21:46:33 -0400 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l931kWMm007816; Wed, 3 Oct 2007 01:46:32 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 <0JPB00001BJNCD00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM); Tue, 02 Oct 2007 19:46:32 -0600 (MDT) Received: from [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 <0JPB00ARUBLHFU00@mail-amer.sun.com>; Tue, 02 Oct 2007 19:46:31 -0600 (MDT) Date: Tue, 02 Oct 2007 18:46:31 -0700 From: Chris Newman Subject: Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP In-reply-to: <46FF783D.7090904@gmx.net> To: Hannes Tschofenig , apps-REVIEW@ietf.org Message-id: <69CC0AC5EB46F7B9D4CE3495@[10.1.110.5]> 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> <46FF783D.7090904@gmx.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Cc: keyprov@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 on 9/30/07 12:19 +0200: > 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. I largely support BCP 56 and as an IESG member I consider it my duty and within my authority to enforce that BCP using my best judgment. However, some of the advice it gives could be updated to make it better and it could use advice in additional areas -- I would support an effort to revise it, although the present HTTP WG proposal may not be the right place to do that work. I'm uncomfortable when my best technical judgment disagrees with common practice and am unlikely to use my IESG authority to permanently block forward progress on a document in that case. However, when I'm aware of a BCP rule and agree with it, I consider it my duty at a minimum to verify the community considered the rule and had explicit community rough consensus to violate it. > (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? I'll give two examples of HTTP-based protocols with separate ports where that was clearly the right technical choice in my opinion: IPP: RFC 2910 SIP: RFC 3261 I'll also mention that the Mail Submission protocol runs on port 587 primarily, but can also run on port 25. That's a practical way to (1) remain backwards compatible with deployed usage or limitations. (2) provide a separate port when it's helpful to avoid middle-box restrictions on an overused/abused port like port 25. It's my technical opinion there should be a separate port registered for HTTP access to information used to validate security credentials (CRLs, OCSP, etc) with port 80 as a fallback for situations where the separate port can't be used and for legacy use. It's plausible to build an Internet service where port 80 was intercepted by default for the authentication screen, but this other port was (partially) open so a client can get security information necessary to verify the interception HTTP server's credentials. I think that would be a better architecture than running everything over port 80 and forcing the port 80 application-level middle-boxes to become ever more sophisticated and failure prone. I have voted DISCUSS for discussion on this topic with document authors, but I have not yet blocked forward progress on any documents on this basis. > (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). For things that only run on port 80, I generally wouldn't expect a separate URL scheme. > (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. To be precise: I have not yet seen any evidence that WSDL is useful. However, I have not educated myself on the protocol sufficiently to have formed an opinion on whether or not it is useful. > (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-delive >>> ry >>> >>> -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 > _______________________________________________ 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 1Icd4L-0002yX-5T; Tue, 02 Oct 2007 04:25:29 -0400 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1Icd4J-0002nI-3m for apps-review-confirm+ok@megatron.ietf.org; Tue, 02 Oct 2007 04:25:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icd4E-0001x1-95 for apps-REVIEW@ietf.org; Tue, 02 Oct 2007 04:25:22 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Icd45-00042D-Mc for apps-REVIEW@ietf.org; Tue, 02 Oct 2007 04:25:14 -0400 Received: (qmail invoked by alias); 02 Oct 2007 08:25:10 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp014) with SMTP; 02 Oct 2007 10:25:10 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+H3dFN/VeHhYfcP5A60akkJ3RhbD1ivM2GQfdBhN nyKPDCmER5qvlY Message-ID: <47020065.50104@gmx.net> Date: Tue, 02 Oct 2007 10:25:09 +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> <46FF783D.7090904@gmx.net> <46FF8417.6090203@gmx.de> In-Reply-To: <46FF8417.6090203@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: 2409bba43e9c8d580670fda8b695204a 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 Julian, I believe the first thing is to get some feedback from this group whether they think some of my observations are indeed correct. If the suggestions in RFC 3205 (BCP 56) are still correct then I suspect we need to modify a few protocols. (I also realize that BCP 56 is not providing strict rules but at least I got confused by the guidelines it provides.) Ciao Hannes Julian Reschke wrote: > 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