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