HTTP: Параметры пути

Изучаю RFC 2068 — Протокол Передачи Гипертекста - HTTP/1.1 В описание синтаксиса URI есть упоминание параметров пути и параметров запроса. Кто-нибудь может объяснить(желательно в примерах):
Разницу между параметрами пути и параметрами запроса со стороны клиента и со стороны сервера Практическую пользу(или ущербность) от использования параметров пути.
UPDATE HTTP URL Path Parameter Syntax -- разъяснения по синтаксису RFC 3986 -- Описание URI, раздел 3.3. Path (см. последний абзац)

Ответ

Синтаксис URI не специфицирует никакого синтаксиса для параметров, пути и запроса. Он лишь разделяет путь и строку запроса. Размещение в этих сегментах каких-либо параметров к синтаксису URI уже никак не относится, это особенности реализаций (веб-фреймворков и приложений).
Синтаксис определяет для них набор "подразделителей" (sub-delims)::
sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="
Они не имеют никакой значимости в URI кроме лишь того, что относятся к зарезервированным символам, а потому их %-экранированные аналоги им не эквивалентны. Это позволяет использовать их в чистом виде в синтаксических конструкциях и в экранированном виде для значений/данных.
Сколько-нибудь широко сейчас используется такая форма параметров в строке запроса

http://хост/путь?параметр1=значение1&параметр2=значение2#фрагмент _______________________________________
Такую структуру типично называют "query parameters" (параметры запроса).
Обратите внимание, что & и = есть в sub-delims, поэтому названиях и значениях параметров можно использовать %26 (экр. &) и %3D (экр. =), не ломая стурктуру параметров, при этом получая их после разбора в чистом, неэкранированном виде.
Например, в строке запроса %26=%3D&%3D=%26 по этому соглашению записаны:
параметр & со значением = параметр = со значением &

Что же до параметров пути, похоже, что они практически вымерли. Мне не довелось работать ни с одним веб-инструментарием, который бы их поддерживал.
Единственная известная мне среда (и с ней я не работал) где я их видел, это Java-сервлеты. Спецификация сервлетов ссылается на них, но не определяет. Беспорядок.
Одно из применений этого механизма в сервлетах это отслеживание сессий в ситуациях, когда клиент не принимает куки; пример такого URL (спецификация сервлетов оперирует именно URL):
http://www.myserver.com/catalog/index.html;jsessionid=1234 ________________
С немалой вероятностью, если вы решите их использовать, вам придётся реализовывать их разбор и формирование самостоятельно. Лишние усилия. Существенный минус.

Для сервера и клиента в общем случае разницы между ними никакой нет. То есть, это разные сущности, у них разная семантика, но технически они ведут себя однаково. (В отличие от, скажем, фрагмента, который может не передаваться клиентом на сервер вовсе.)