Personally I firmly advocate nowadays that the underlying technology has no business being present in a URI.
So, rather than
http://example.com/catalogue/page1.html or
http://example.com/catalogue.php?page=1 I'd be setting the server up to deal with
http://example.com/catalogue/1 and so forth.
The
.html extension seems harmless, whereas extensions like
.php,
.asp or
.aspx become a nuisance when you move to a different platform and are left with a shedload of redirects that you have to maintain for ever. But even
.html is inappropriate IMNSHO, because a URI is supposed to identify a
resource (or the location of a resource, in the case of a URL), and by including
.html you're restricting it to identifying a specific
representation of that resource.
Therefore I would argue that, although you may support URIs that include content-type information such as
.html, the canonical form of the URI should be in the form that contains no information about the content-type of the resource, and certainly no information about something so completely irrelevant to the identification of a resource as the technology used (at the moment) to
serve that resource.
Note that, if you do support the version with the type-denoting-extension in addition to the canonical version, you should take the additional steps necessary to ensure that only the canonical form is indexed by search engines, or you'll risk being penalised for having duplicate content, and also risk being forced to maintain the non-canonical versions.
RESTful Web Services by Richardson and Ruby is an excellent book on the correct use of HTTP, including a detailed discussion of URL design.