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: 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. To emphasise what is already defined in [RFC3261], UASa MUST NOT use the "transport=tls" parameter. typo "UASa" (unless it's mine) 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. _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
