|
|
|
|
Found 11 records.
Errata ID: 316
Status: Verified
Type: Technical
Reported By: RFC Editor
Date Reported: 2003-10-03
In Section 25.1:
digest-uri-value = rquest-uri ; Equal to request-uri as
specified by HTTP/1.1
It should say:
digest-uri-value = request-uri ; Equal to request-uri as
specified by HTTP/1.1
Errata ID: 1051
Status: Verified
Type: Technical
Reported By: Alexandre Machado
Date Reported: 2007-08-23
Verifier Name: Robert Sparks
Date Verified: 2010-04-03
Section 25.1 says:
srvr = [ [ userinfo "@" ] hostport ]
It should say:
srvr = [ [ userinfo ] hostport ]
Notes:
The character "@" should not appear in this rule since it already appears at the end of the rule "userinfo":
userinfo = ( user / telephone-subscriber ) [ ":" password ] "@"
According to the use of rule "userinfo" in other rules such as "SIP-URI" and "SIPS-URI", the correct place of character "@" is really at the end of rule "userinfo" and not in all other rules using it.
Errata ID: 1073
Status: Verified
Type: Technical
Reported By: Marco Ambu
Date Reported: 2005-12-15
Verifier Name: Robert Sparks
Date Verified: 2010-04-03
I would like to show you an error in RFC 3261. I've discussed in SIP-implementors mailing list too. in RFC 3261 page 44 par 8.1.3.4 there is an example of URI (contact URI) with uri headers: sip:user@host?Subject=foo&Call-Info=<http://www.foo.com> I've noticed that URI header "Call-Info" has a value with characters not allowed in uri headers. The BNF says that an header value must contain characters in hnv-unreserved or unreserved or escaped but '<' and '>' are not in that set. The right example should be the following: sip:user@host?Subject=foo&Call-Info=%3Chttp://www.foo.com%3E
It should say:
[not submitted]
Notes:
from pending
Errata ID: 1470
Status: Verified
Type: Technical
Reported By: Iņaki Baz Castillo
Date Reported: 2008-07-14
Verifier Name: Robert Sparks
Date Verified: 2010-04-03
Section 17.2.2 says:
If the TU passes a final response (status codes 200-699) to the server while in the "Proceeding" state, the transaction MUST enter the "Completed" state...
It should say:
If the TU passes a final response (status codes 200-699) to the server while in the "Trying" or "Proceeding" state, the transaction MUST enter the "Completed" state...
Notes:
"17.2.2 Non-INVITE Server Transaction" doesn't consider the case in which the transaction state is "Trying" and the transaction receives from the TU a final response.
It's totally possible that TU sends a final response without sending before a provisional response. Note that this case is perfectly valid in the diagram of page 139.
Errata ID: 2051
Status: Verified
Type: Editorial
Reported By: Cullen Jennings
Date Reported: 2010-02-24
Verifier Name: Robert Sparks
Date Verified: 2010-05-23
Section 26.3.1 says:
Proxy servers, redirect servers, and registrars SHOULD possess a site certificate whose subject corresponds to their canonical hostname.
It should say:
Proxy servers, redirect servers, and registrars SHOULD possess a site certificate whose subject corresponds to the DNS name other SIP devices will use to reach them.
Notes:
The term hostname seemed to make some people think if you had two sip servers for the domain example.com with hostnames host1 and host2, the the cert should have host1.example.com when in fact the sip signaling always used exmaple.com and the cert should have a example.com as the name.
Errata ID: 678
Status: Held for Document Update
Type: Technical
Reported By: Matthew S. Harris
Date Reported: 2006-08-14
Held for Document Update by: Cullen Jennings
Section 25.1 says:
On page 220, it says "The TEXT-UTF8-TRIM rule is used for descriptive field contents that are n t quoted strings, where leading and trailing LWS is not meaningful." (And no, I'm not talking about the "n t" typo.) The rule for TEXT-UTF8-TRIM is TEXT-UTF8-TRIM = 1*TEXT-UTF8char *(*LWS TEXT-UTF8char) TEXT-UTF8char = %x21-7E / UTF8-NONASCII which pretty clearly says that the final character of TEXT-UTF8-TRIM cannot be whitespace. TEXT-UTF8-TRIM appears only as the value of a header field, and the rule for message-header does not generate trailing whitespace either. So the text talks about trailing whitespace, which seems reasonable because whitespace is allowed in many other places, but the grammar does not allow it. Was trailing whitespace intended?
It should say:
[not submitted]
Notes:
from pending
Errata ID: 832
Status: Held for Document Update
Type: Technical
Reported By: Marco Ambu
Date Reported: 2006-01-11
Held for Document Update by: Robert Sparks
I would like to show you an ambiguity in RFC 3261. The ABNF for SIP in RFC 3261 page 227 defines header Accept as "Accept = "Accept" HCOLON [accept-range *(COMMA accept-range)]. Expanding this form we have: Accept = "Accept" HCOLON [( (...) *(SEMI m-parameter) *(SEMI accept-param) ) *(COMMA accept-range)] For example we can have Accept: application/sdp;m_extension_parameter=value1;accept_extension_param=value2;q=0.5 We know from RFC 3261 that q is an accept-param. We don't know how to consider the first two unknown parameters: how to distinguish from m-parameter and accept-param? While in other cases RFC 3261 shows the rules to solve ambiguities (for example how to consider the parameters in a Contact URI if the URI is not enclosed in angular brackets) I have not found any suggestion for this specific case in RFC 3261.
It should say:
[not submitted]
Notes:
from pending
Errata ID: 1682
Status: Held for Document Update
Type: Technical
Reported By: Iņaki Baz Castillo
Date Reported: 2009-02-10
Held for Document Update by: Robert Sparks
Section 20.7 says:
Authorization: Digest username="Alice", realm="atlanta.com", nonce="84a4cc6f3082121f32b42a2187831a9e", response="7587245234b3434cc3412213e5f113a5432"
It should say:
Authorization: Digest username="Alice", realm="atlanta.com", nonce="84a4cc6f3082121f32b42a2187831a9e", response="7587245234b3434cc3412213e5f113a5"
Notes:
'response' field in original example has 35 hexadecimal characters while they must be 32:
dresponse = "response" EQUAL request-digest
request-digest = LDQUOT 32LHEX RDQUOT
Errata ID: 1471
Status: Held for Document Update
Type: Editorial
Reported By: Iņaki Baz Castillo
Date Reported: 2008-07-14
Held for Document Update by: Robert Sparks
Section 17 says:
Additionally, in the case of an INVITE request, the client transaction is responsible for generating the ACK request for any final response accepting a 2xx response.
It should say:
Additionally, in the case of an INVITE request, the client transaction is responsible for generating the ACK request for any final response excepting a 2xx response.
Notes:
"accepting a 2xx response" => "excepting a 2xx response"
Errata ID: 1472
Status: Held for Document Update
Type: Editorial
Reported By: Iņaki Baz Castillo
Date Reported: 2008-07-14
Held for Document Update by: Robert Sparks
Section 25.1 says:
The TEXT-UTF8-TRIM rule is used for descriptive field contents that are n t quoted strings,
It should say:
The TEXT-UTF8-TRIM rule is used for descriptive field contents that are not quoted strings,
Notes:
"are n t" => "are not"
Errata ID: 1742
Status: Rejected
Type: Technical
Reported By: Pankaj Jain
Date Reported: 2009-03-25
Rejected by: Robert Sparks
Date Rejected: 2010-05-23
Section 17.1.1.2 says:
Timer D reflects the amount of time that the server transaction can remain in the "Completed" state when unreliable transports are used.
It should say:
Timer D reflects the amount of time that the client transaction can remain in the "Completed" state when unreliable transports are used.
Notes:
server transaction => client transaction
--VERIFIER NOTES--
The original text is correct. The value (and reason) for timer D is to reflect what's happening in the server transaction. See the discussion of Timer H that immediately follows the text quoted above.