Thanks. See below.
> -----Original Message----- > From: Scott Brim [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 25, 2008 12:59 > To: [email protected]; Cullen Jennings; > [EMAIL PROTECTED]; Audet, Francois (SC100:3055) > Subject: gen-art review of draft-ietf-sip-sips-08.txt > > I have been selected as the General Area Review Team > (Gen-ART) reviewer for this draft (for background on Gen-ART, > please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html ). > > Document: draft-ietf-sip-sips-08.txt > Reviewer: Scott Brim > Review Date: 25 Sep 2008 > IETF LC End Date: 02 Oct 2008 > > Summary: This draft is ready for publication as a Proposed > Standard RFC. > > Comments: > > I'm not an expert, and I didn't have time to thoroughly > cross-check all the pieces of this draft (there are a LOT of > overlaps of information in different parts of the draft), but > at the level of depth I got to, it's very good. Here are a > few small suggestions in case there is another version: The overlap is caused by our very strict rules on having seperate sections for UAC, UAS, Proxy, etc., and having > Because registering with a SIPS Contact header field implies a > binding of both a SIPS Contact and a corresponding SIP Contact to > the AOR, a UA MUST NOT include both the SIPS and the SIP version of > the same Contact header field in a REGISTER request; the UA MUST > only use the SIPS version in this case. Similarly, a UA SHOULD NOT > register both a SIP Contact header field and a SIPS Contact header > field in separate registrations as the SIP Contact header field > would be superfluous. If it does, the second registration replaces > the first one (e.g., a UA could register first with a SIP Contact > header field - meaning it does not support SIPS- and later register > with a SIPS Contact header field (meaning it now supports SIPS). > > Might want to clarify that a second registration with a SIP > Contact header field removes the SIPS registration. OK, I can add the following sentence at the end of the paragraph: Similarly, if a UA registers first with a SIPS Contact header field and later registers with a SIP Contact header field, that SIP Contact header field replaces the SIPS Contact header field. > To emphasise what is already defined in [RFC3261], UASa MUST NOT > use the "transport=tls" parameter. > > typo "UASa" (unless it's mine) Correct, I will fix the typo. > A registrar MUST only accept a binding to a SIPS Contact header > field > > "MUST only" ... the "only" isn't very visible. You might > capitalize ONLY, or change the sense of the sentence to make > this a MUST NOT or a MUST. Actually, "MUST ONLY" is not defined in RFC 2119 so we can't really say this, but it doesn't matter anyway since the english is not right. It should be worded as follows: A registrar MUST accept a binding to a SIPS Contact header field only if all the appropriate [...] I will fix. _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
