Subject: CONFIRM message in http used as transport

From: "Kwon, YongChul" <[email-masked]>
Date: Mon, 6 Mar 2000 20:50:16 +0900

hello.

how can CONFIRM message be sent over http which used as transport of CMP?

the 3 way message exchange seems couldn't be done in http.

anyone who has an idea about this?

end entity can always stop the connection suddenly
( it makes things harder :-( ).

please tell me your ideas about that!

Thanks.

---

From: "Life is hard, and then you die." <[email-masked]>
Date: Fri, 10 Mar 2000 08:43:40 -0800 (PST)

> ( it makes things harder :-( ).

The different messages in a transaction are not associated with each
other via the connection. The association is done via the transactionID
field in the PKIHeader. So the Confirm may be sent on the same or on a
different connection, doesn't matter.  In fact, you may even be getting
requests for multiple transactions on the same connection, all
interleaved (i.e. just because a message arrives on the same connection
as another one doens't mean it belongs to the same transaction) - this
may happen, for example, when an http proxy sits between the client and
the server. You always use the transactionID to figure out which
transaction a messsage belongs to. The only requirement is that you send
back responses in the same order as the requests came in (this is an
http requirement, actually).

Note that this is the same when using TCP directly as transport.

Have a look at the latest CMP draft (draft-ietf-pkix-rfc2510bis-00.txt)
- it explains the transactionID field a bit better. Also, take a look at
the transport drafts (draft-ietf-pkix-cmp-http-00.txt and
draft-ietf-pkix-cmp-tcp-00.txt).

  Cheers,

  Ronald