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

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 13 Sep 2007 14:56:54 +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-delivery-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

---

From: Chris Newman <[email-masked]>
Date: Fri, 21 Sep 2007 14:23:56 -0700

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:

> 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:
> Do people on this list have an opinion about the content they would like to
> see in these type of documents?

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 22 Sep 2007 11:40:42 +0200

Hi Chris,

thanks for the response.

Chris Newman wrote:

> I expect HTTP bindings to address the concerns raised in BCP 56.  

I will read through 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 am not sure whether the separate port number idea will find a lot of 
excitement since the downside is that a network operator that just does 
not care about the specific protocol (even through he does not mind 
allowing end hosts to run it) will essentially block it.

>
> 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 have received this type of feedback from a couple of different sides 
already.

>
> 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.
We will certainly make use of an XML schema.

> I haven't reviewed the DSKPP draft yet.
I need to see whether I need to make changes based on the 
above-mentioned BCP. Hence, I would advice to wait a bit.

Ciao
Hannes

>> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-http-location-delivery 
>>
>> -01.txt
>>

---

From: Julian Reschke <[email-masked]>
Date: Sat, 22 Sep 2007 12:09:13 +0200

Hannes Tschofenig wrote:
 > ...

Out of curiosity? How exactly is XML Schema superior with respect to 
data typing?

Best regards, Julian

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 22 Sep 2007 14:45:05 +0200

Hi Julian,

Julian Reschke wrote:
>>> XML formats, whereas XML Schema is better for XML formats with 
>>> strong value typing.
I don't think that there is a difference between the two with this 
respect. For protocols we don't put too many constraints on data types 
in the schema anyway since there will not be any validation of incoming 
messages since you have to parse them anyway.

Relax NG vs. XML schema: We currently already have the XML schema in the 
document and nobody in the group suggested to change it.
When we picked a Relax NG schema for LoST (a different protocol) in the 
ECRIT WG some folks did not like it due to the lack of available tools. 
Programmers told us that they translated the Relax NG schema found in 
the document into a XML schema. So, the Relax NG schema was not of great 
value to them even though we thought it was much more convenient to use.

Ciao
Hannes

---

From: Julian Reschke <[email-masked]>
Date: Sat, 22 Sep 2007 15:14:28 +0200

> messages since you have to parse them anyway.

That's what I thought as well.

> value to them even though we thought it was much more convenient to use.

In WebDAV, we used DTD fragments to describe the formats (with the known 
shortcomings with respect to namespaces, element ordering and 
extensibility).

Replacing this with XML Schema would be IMHO a non-starter, because XML 
Schema has the same constraints with respect to extensibility as DTDs. 
Relax NG in its compact notation form looks very good, both because it's 
actually readable in a spec, and because it does all "we" (people 
working on WebDAV specs) need -- it works well with namespaces, and 
extensibility can actually be defined properly.

People who actually want to validate programmatically -- and in 
protocols it's not really clears that this is a good idea -- can either 
use the few Relax NG validators, or convert to XML Schema (or DTD) using 
Trang. And that's IMHO the biggest advantage: the RNC format is as 
readable as DTD, but it's better for defining protocol constraints than 
XNL Schema (1.0). And people who need XML Schema can still easily 
convert to it.

I think that's one of many things the AtomPub WG got right in RFC4287.

Best regards, Julian

---

From: Barry Leiba <[email-masked]>
Date: Sat, 22 Sep 2007 10:10:52 -0400

> excitement since the downside is that a network operator that just does not
> care about the specific protocol (even through he does not mind allowing end
> hosts to run it) will essentially block it.

Hannes, I'm not sure I understand what you're saying here, so maybe you should 
explain more.  What I read it as saying is that you don't like using a separate 
port because you *want* to sneak through firewalls without telling the firewall 
administrators.  There be dragons, and that was Chris's point.  A protocol that 
looks like HTTP but is used for a different purpose should be on a different port.

Actually, I've had this argument with people within my company too, and it might 
be that we aren't clear about what the port-number list *is*: it should be more 
like a list that maps *applications*, rather than *protocols*, to ports.  In most 
cases, that's the same.  But with SMTP and HTTP, at least, it's not.

Barry

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 22 Sep 2007 16:24:20 +0200

Hi Barry,

Barry Leiba wrote:
> Hannes, I'm not sure I understand what you're saying here, so maybe 
> you should explain more.  What I read it as saying is that you don't 
> like using a separate port because you *want* to sneak through 
> firewalls without telling the firewall administrators.  There be 
> dragons, and that was Chris's point.  A protocol that looks like HTTP 
> but is used for a different purpose should be on a different port.
>
> Actually, I've had this argument with people within my company too, 
> and it might be that we aren't clear about what the port-number list 
> *is*: it should be more like a list that maps *applications*, rather 
> than *protocols*, to ports.  In most cases, that's the same.  But with 
> SMTP and HTTP, at least, it's not.
>
I agree that it would be nice to allow administrators to make these type 
of decisions.

In other areas in the IETF folks also had the idea that the network 
administrators are going to configure their networks in such a way that 
the protocols would work. SIP and NAT/Firewall traversal is a good 
example. It took a while to realize that this is not a good approach.

DSKPP is an application layer protocols that allows an end point to 
retrieve keying material for usage with other protocols. Typically, the 
client on an end host will interact with a server in it's home network.
If I am in a hotel network and want to obtain new keying material for 
usage with my VPN client and the network administrator of the hotel 
network does not know the port number used by DSKPP then it might happen 
that I just cannot use the protocol.

Now, there are also other protocols flying around in this space; 
actually a large number of protocols in this identity management space 
that happen to run on top of HTTP without using an additional port (at 
least to my knowledge).

I don't see why these protocol should work in all environments (where 
HTTP traffic is allowed to bypass a middlebox) but a protocol developed 
within the IETF isn't just because there is this idea of a "clean 
architecture".

Does my reasoning make sense to you?

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 30 Sep 2007 12:19:41 +0200

Hi Lisa,
Hi Chris,
Hi all,

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.

There are a couple of issues that require consideration when defining an 
HTTP transport:

(a) MIME-types. I believe we are doing fine with the usage of XML and 
the registration of a new mime type.

http://tools.ietf.org/html/draft-ietf-pkix-scvp-33 on the other hand 
uses different mime types for request and resonse messages. I don't 
think that this is necessary.

(b) No new HTTP method seems to be needed
(We don't do that in the DSKPP draft anyway)

(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?

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

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

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

---

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