RE: [KEYPROV] Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP
Chris Newman <Chris.Newman@Sun.COM> Tue, 09 October 2007 05:34 UTC
Return-path: <apps-review-bounces@ietf.org>
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 <Chris.Newman@Sun.COM>
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" <pbaker@verisign.com>, Hannes Tschofenig <Hannes.Tschofenig@gmx.net>, 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 <apps-review.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/apps-review>, <mailto:apps-review-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/apps-review>
List-Post: <mailto:apps-review@ietf.org>
List-Help: <mailto:apps-review-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/apps-review>, <mailto:apps-review-request@ietf.org?subject=subscribe>
Errors-To: apps-review-bounces@ietf.org
Hallam-Baker, Phillip wrote on 10/4/07 12:11 -0700: > <hat chair=off> > > 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
- [APPS-REVIEW] Review of HTTP Binding for DSKPP Hannes Tschofenig
- [APPS-REVIEW] Review of HTTP Binding for DSKPP Hannes Tschofenig
- [APPS-REVIEW] Re: Review of HTTP Binding for DSKPP Hannes Tschofenig
- Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP Chris Newman
- Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP Hannes Tschofenig
- Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP Julian Reschke
- Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP Hannes Tschofenig
- Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP Julian Reschke
- Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP Barry Leiba
- Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP Hannes Tschofenig
- Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP Hannes Tschofenig
- Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP Julian Reschke
- Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP Hannes Tschofenig
- Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP Chris Newman
- RE: [KEYPROV] Re: [APPS-REVIEW] Review of HTTP Bi… Hallam-Baker, Phillip
- RE: [KEYPROV] Re: [APPS-REVIEW] Review of HTTP Bi… Chris Newman
- Re: [KEYPROV] Re: [APPS-REVIEW] Review of HTTP Bi… Mark Nottingham
- RE: [KEYPROV] Re: [APPS-REVIEW] Review of HTTP Bi… Hallam-Baker, Phillip
- RE: [KEYPROV] Re: [APPS-REVIEW] Review of HTTP Bi… Hallam-Baker, Phillip
- Re: [KEYPROV] Re: [APPS-REVIEW] Review of HTTP Bi… Julian Reschke
- RE: [KEYPROV] Re: [APPS-REVIEW] Review of HTTP Bi… Hallam-Baker, Phillip