[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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 at ietf.org
https://www1.ietf.org/mailman/listinfo/apps-review




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







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