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

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

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

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