Subject: [Sip] SIP Success

From: Allison Mankin <[email-masked]>
Date: Thu, 07 Mar 2002 14:30:09 -0500

SIP chairs and working group,

The IESG approved the set of five documents that were Last Called,
and approved the request for Fast Track RFC numbering that will
enable 3GPP to reference SIP bis.  I'll write a separate note about
the Fast Track.

As Area Director, I want to express my admiration for your amazingly 
hard work, and the high quality (almost always) and energy level of 
your discussions.

Especial admiration is due to your document editors for their
skill and responsiveness.

The IESG and the RFC Editor made a few requests for clarifying
changes.  When the specs are sent to the RFC-Editor in an hour
or so, they will be accompanied by the following RFC-Editor notes,
which go into the specs automatically (no new i-ds will appear).

Allison

---------

Here are the RFC Editor notes for SIP, with thanks in advance
to the RFC Editor for the support for this.

draft-ietf-sip-rfc2543bis-09.txt -

1.
This is a note addition that responds to an Area Director review
identifying a problem that cannot be resolved with existing
specifications.  

 Note that currently there does not exist an exact IETF definition of 
 case-insensitivity applied to the whole ISO 10466 character set, 
 thus implementations should avoid dependencies on non-ASCII 
 case-matching rules (or lack thereof) until an IETF definition and 
 specification exists. 

Please add the above paragraph in two places in 
draft-ietf-sip-rfc2543bis-09.txt, which are;

Section 7.3.1

                                 Tokens are always case-insensitive.
   Unless specified otherwise, values expressed as quoted strings are
   case-sensitive.

   [Add the note as a new paragraph starting after the quoted sentence]

Section 19.1.4

        o Comparison of the userinfo of SIP and SIPS URIs is case-
          sensitive.  This includes userinfo containing passwords or
          formatted as telephone-subscribers. Comparison of all other
          components of the URI is case-insensitive unless explicitly
          defined otherwise.

   [Add the note as a continuation of the quoted bullet]

2.

In draft-ietf-sip-rfc2543bis-09.txt, Section 20.12 

      third paragraph "coding" should be "encoding".

3. draft-ietf-sip-srv-06.txt

This is a clarifying change that removes an appearance of
inconsistency between this document and the bis protocol
document.  It responds to an Area Director review.

In draft-ietf-sip-srv-06.txt, make the following substitution:

OLD: 
 
For NAPTR records with SIPS protocol fields, the domain name in the 
query and the domain name in the replacement field MUST both be valid 
based on the site certificate handed out by the server in the TLS 
exchange. Similarly, the domain name in the SRV query and the domain 
name in the target in the SRV record MUST both be valid based on the 
same site certificate. Otherwise, an attacker could modify the DNS 
records to contain replacement values in a different domain, and the 
client could not validate that this was the desired behavior, or the 
result of an attack.  
 
NEW:
 
For NAPTR records with SIPS protocol fields, the domain name in the query 
and the domain name in the replacement field MUST NOT be rooted in a 
different domains (that is, if the query is for 'example.com', the answer 
must not return a replacement field with a domain suffix other than 
'example.com', such as '_sips._tcp.differentdomain.com'). Similarly, for 
SIPS queries the domain name in the SRV query and the domain name in the 
target in the SRV record MUST NOT be rooted in different domains. 
Otherwise, an attacker could modify the DNS records to contain replacement 
values in a different domain, and the client could not validate that this 
was the desired behavior, or the result of an attack.  

4. draft-ietf-sip-100rel-06.txt

Replace the whole abstract with the following one, per request
by the RFC-Editor for a more informative abstract, suitable
for stand-alone understanding.

The Session Initiation Protocol (SIP) is a transactional
request-response protocol for the initiation, management, and
termination of sessions. SIP provides two types of responses to a
request. Final responses, which are in the range of 200 to 699, complete
the transaction, and are sent reliably by SIP. Provisional responses,
also known as informational responses, precede the final response, and
provide status or progress information to the requestor. SIP does not
provide reliability for these responses end-to-end. However, many
applications of SIP have arisen which require these messages to be sent
reliably end-to-end. This specification defines an extension to SIP
using a new request method, called PRACK, which can be used to guarantee
reliability of provisional responses.

5. 

The RFC Editor requested expansion of the acronym SIP and SDP 
where they are used in the titles and abstracts and this was
agreed to.

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip