Thanks. I will make all those changes.
> -----Original Message----- > From: Hans Persson [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 05, 2007 02:25 > To: Audet, Francois (SC100:3055) > Cc: Dean Willis; IETF SIP > Subject: Re: [Sip] WGLC for draft-ietf-sip-sips-05.txt > > fre 2007-06-29 klockan 09:42 -0500 skrev Dean Willis: > > > I'm pleased to announce that the authors think that the > SIPS draft is > > ready for working group last call. This draft has had the > privilege of > > more review prior to WGLC than most of our other efforts, > so perhaps > > it won't be too controversial. > > > > Please make a final read through the draft and bring any > comments back > > to this list. > > > I've gone through the diff between the current version and > the last one > I read, and on the whole it looks good to me. > > Some editorial nits are listed below. > > > Section 3.1.1, para 1: > > > the Proxy is the TLS server side. This directionality implies that > > "proxy" > > > directions (e..g, an incoming call), the UA must keep the TLS > > "e.g." > > > Section 3.1.1, para 2: > > > connection also solves the NAT and Firewall problem as it ensures > > "firewall" > > > Section 3.1.2, para 1: > > > place, the UAC would therefore take on the role of the TLS > Client and > > "client" > > > SIP, a UA or a Proxy act both as UAC and UAS depending on > if they are > > "proxy" > > > is very convenient. This allows for TLS connections to be set-up or > > "set up" > > > Section 3.1.2, para 3: > > > most residential SIP deployments for example. Mutual TLS > can be used > > Insert comma after "deployments". > > > in those environments, but only if the connection is always > stated by > > "stated" is a strange word here. Do you mean "started"? > > > Section 3.1.2, last para: > > > For this reasons, mutual TLS is mostly used in server-to-server > > "this" -> "these" > > > Section 3.1.3, para 4: > > > message (From, To, Request-URI, Contact header field, Route, etc.). > > Why "Contact header field" and not just "Contact" like for the others? > > > Section 3.4, para 6: > > > allowed, which would preclude the use of NATs or Firewalls. > > "firewalls" > > > Section 4.1, para 3: > > > SIP URI, it SHOULD respond with a 418 (SIPS Not Allowed). UAS that > > do not support the SIPS URI scheme altogether "SHOULD reject the > > "UAS" would be more readable as "UASs". > > Change "altogether" to "at all". > > > Section 4.1, last para: > > > response code 419 (SIPS Required) > > Missing period at end of sentence. > > > Section 4.1.2, para 8: > > > reject requests using the SIP Scheme with 419 (SIPS Required). A UA > > "scheme" > > > Section 4.2, para 5: > > > response, it MUST NOT recurse on it. The Proxy SHOULD forward the > > "proxy" > > > Section 4.3, para 1: > > > Using a Redirect Server with TLS instead of using a Proxy has some > > "redirect server", "proxy" > > > established connection between the Proxy and the UAS (such as with > > "proxy" > > > Section A.3: > > > (similar to what the transport=tls used to mean) has been suggested > > Remove "the". > > > Hans > > -- > Hans Persson <[EMAIL PROTECTED]> Ingate - Firewalls with SIP & NAT > Ingate Systems AB +46 13 210857 http://www.ingate.com/ > > Private: <[EMAIL PROTECTED]> http://www.lysator.liu.se/~unicorn/ > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
