errata logo graphic

Found 1 record.

Status: Held for Document Update (1)

RFC4483, "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", May 2006

Source of RFC: sip (rai)

Errata ID: 79

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2006-06-20
Held for Document Update by: Robert Sparks

 

(1)  Inconsistent Ref. to URI Specification

The text of RFC 4483 repeatedly refers to  "RFC2396 [7]" .
This is misleading.
Every occurrence of "RFC 2396" should be replaced by "RFC 3986".

Note: Section 10.1. Normative References, holds the proper
      reference to STD 66, RFC 3986 in its item [7] !


(2)  Outdated Ref. to HTTP 1.1 Specification

Item [4] of Section 10.1 Normative References, points to the
outdated original specification for HTTP 1.1, RFC 2016,
which has been obsoleted by RFC 2616, 7 years ago.

Since the HTTP ETAG mechanism (referred to in the text of RFC 4483)
has been clarified substantially in RFC 2616, the reference to
"RFC2068 [4]" in Section 4, near the bottom of page 5 of RFC 4483,
should bhave been "RFC2616 [4]", and the item [4] of Section 10.1,
on page 15 of RFC 4483, should be replaced by a citation of RFC 2616
according to `rfc-ref.txt`.


(3)  (Mis)Use of SIP Terminology

Unfortunately, RFC 4483 substantially adds to the confusion
of precisely defined SIP (and other) terminology.

In particular, *all* occurrences of the term "Header[s]" in RFC 4483
should be corrected to say "Header Field[s]".

RFC 4485, published just 2 weeks ahead of RFC 4483, explicitely
poses the requirement for SIP extension documents to follow the
established SIP terminology -- cf. Section 4.3 of RFC 4485
(page 10), which says:

   Careful attention must be paid to the actual usage of terminology.
   Many documents misuse the terms header, header field, and header
   field values, for example.  Document authors SHOULD do a careful
   review of their documents for proper usage of these terms.

See also RFC 4249, Section 3.1.1 (page 3) for a similar statement on
the proper usage of these terms in the context of IMF and MIME, and
related (extension) specifications.

Notes:

from pending


Report New Errata