RE: [KEYPROV] Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP

["Hallam-Baker, Phillip" <pbaker at verisign.com>]

> From: Chris.Newman at Sun.COM [mailto:Chris.Newman at Sun.COM] 

> > 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.

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 
> 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.

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 
> 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.

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. 


> > 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".

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. 

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. 
> > 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.

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. 

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. 

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. 


_______________________________________________
APPS-REVIEW mailing list
APPS-REVIEW at ietf.org
https://www1.ietf.org/mailman/listinfo/apps-review