Document: draft-loreto-simple-im-srv-label-00.txt Reviewer: Miguel Garcia Review Date: 2008-04-09 Review Due: 2008-04-11 Review Type: Expert Comments: - I have one substantial comment. It is with respect the scope of the draft. It seems that the draft is trying to achieve two goals in the same shot: a) register a couple of SRV labels with IANA; b) Specify how SIP IM and Presence use DNS SRV to resolve im: and pres: URIs. The problem is that b) is already specified in RFC 3861 Section 3. So, I recommend to get b) out of the scope of the draft and focus on a) Nits: - The title of the draft does not mention Presence, in spite it registers a label for the presence service. Also, remove the word 'registry', because you don't register a 'registry', but a label in a registry. - I would expect the Introduction to give a brief description (max one paragraph) of what SRV records are and how they are structured: "_Service._Proto.Name", so the text can later justify that the _im and _pres labels have been registered as _Service, but not _sip. The text should also add a reference to RFC 2782 (DNS SRV), which is relevant for understanding this draft. - Section 2 says: However if the UA is unable to resolve the IM URI, in order to resolve the IM URI into corresponding SIP URI, it SHOULD perform a SRV lookup for: The text hints that the UA first tries to resolve th IM URI and it if fails, it should try the SRV record. I don' think this is what the text wants to say. I think the text should say that, although there are standard mechanisms for resolving the im and pres URIs (refer to RFC 3861 Section 3), the labels are not registered for SIP. - Also, according to my first comment, I don't get the reason for the SHOULD strength in the following sentence: However if the UA is unable to resolve the IM URI, in order to resolve the IM URI into corresponding SIP URI, it SHOULD perform a SRV lookup for: Is this draft putting a normative requirement to the SIP/SIMPLE application? This draft is not specifying that behavior, therefore, the test should use descriptive text. - Section 2. The text is short in words around the "_pres" SRV label (just one sentence). Furthermore, RFC 3265 is not related to presence, so that RFC is not going to tell me how to resolve a pres URI. Perhaps a better reference is the presence event package RFC 3856. - Security considerations. I think this draft goes beyond its scope. The scope of the draft is to include a registration in the IANA registry. The scope of this draft is not about SIP or DNS procedures, so, it shouldn't mention any of them. I guess a simpler text would be enough, such as: This document merely serves for the registration of DNS SRV labels in the appropriate IANA registry. The does not specify a protocol, therefore, there are no security issues associated with it. - IANA considerations section. This is the core of this document. I think it is not accepted to refer to the "appropriate registry" here, when the draft says: the IANA registers the "_sip" protocol label in the appropriate registry, as follows: The draft needs to explicitly mention the registry by name, which in this case is the 'Instant Messaging SRV Protocol Label Registry'. The same applies to the 'Presence SRV Protocol Label Registry'.