RFC 3261, "SIP: Session Initiation Protocol", June 2002Source of RFC: sip (rai)
Errata ID: 4675
Status: Held for Document Update
Publication Format(s) : TEXT
Reported By: Bruce Florman
Date Reported: 2016-04-21
Held for Document Update by: Ben Campbell
Date Held: 2016-05-05
Section 18.104.22.168 says:
Examples: From: "Bob" <sips:email@example.com> ;tag=a48s From: sip:+firstname.lastname@example.org;tag=887s From: Anonymous <sip:email@example.com>;tag=hyh8
It should say:
Examples: From: "Bob" <sips:firstname.lastname@example.org> ;tag=a48smh2 From: sip:+email@example.com;tag=887s6pa From: Anonymous <sip:firstname.lastname@example.org>;tag=hyh8mtf
I know this is more than a little picayune, but...
Section 19.3 says:
When a tag is generated by a UA for insertion into a request or
response, it MUST be globally unique and cryptographically random
with at least 32 bits of randomness.
This implies that the tag value must be at least 32 bits in size.
Section 25.1 says:
token = 1*(alphanum / "-" / "." / "!" / "%" / "*"
/ "_" / "+" / "`" / "'" / "~" )
tag-param = "tag" EQUAL token
Although the actual representation of the tag value is implementation-specific, since there are only 72 characters available with which to encode it, a tag value with only four characters can represent a maximum of 72^4 distinct numeric values, which is less than the 2^32 values that can be represented by 32 bits by a factor of nearly 160.
Even if the implementation chooses to omit "leading zeros" (or something equivalent), the likelihood of three 32 bit random values all falling in the range of values that can be represented in four characters would be less than one in five million. So even if the given examples are theoretically possible for a conforming implementation, they seem rather misleading.
For a "typical" 32 bit random value, even with base74 encoding, the shortest tag value would require six characters. Given that all three examples (which are also repeated almost unchanged in section 20.20) contain no uppercase ALPHA characters in the tag values, the implied encoding is more likely something like base32 or base36, which would require at least seven characters to represent a typical 32 bit random value. So that's how I'm suggesting that the examples be amended.