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

From: Julian Reschke <[email-masked]>
Date: Sun, 30 Sep 2007 13:10:15 +0200

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

_______________________________________________
KEYPROV mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/keyprov

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 02 Oct 2007 10:25:09 +0200

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

---

From: Chris Newman <[email-masked]>
Date: Tue, 02 Oct 2007 18:46:31 -0700

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
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/apps-review
>
>
>
> APPS-REVIEW mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/apps-review
>

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 4 Oct 2007 12:11:40 -0700

<hat chair=off>

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. 

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.

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.

</hat>

> -----Original Message-----
> From: Chris Newman [mailto:[email-masked]] 
> Sent: Tuesday, October 02, 2007 9:47 PM
> To: Hannes Tschofenig; [email-masked]
> Cc: [email-masked]
> Subject: [KEYPROV] Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP
> 
> > 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
> > 
> > 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-0
0.txt. I 
> > guess we are doing fine there.
> >
> > The IANA registry for the MIME type should look similar to 
> the one in 
> > Section
> > We also need to add a registry for the schema and the 
> namespace (see 
> > Section
> >>> 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:
> >>> 
> >>> like to see in these type of documents?