More follow up: Paul is correct: most implementations do not use sips, and only use sip. Many implementations support TLS with sip:. I would suggest you specify sip or sips and have a note that says sip is only to be used when TLS is supported.
Brian > On Apr 23, 2025, at 11:22 AM, Paul Kyzivat > <[email protected]> wrote: > > Tiru, > > You have mostly addressed my concerns. I've included a few followup questions > below. > > On 4/23/25 1:42 AM, tirumal reddy wrote: > >> 1) NIT: Section 4 - c: (contact) >> This allows sips but not sip URIs. Sips is not widely used. >> Please consider allowing sip URLs. >> Allowing "sip" URI introduces security issues, "sips" offers encrypted >> transport for SIP messages. > > I'm aware of that. Yet, AFAIK sips URIs are rarely used in sip > implementations. (They were added to get through the security review for > RFC3261.) I think there would often be trouble invoking a sips URI. Also, why > isn't there similar concern for the security of mailto? > > But if you think you can't get through a security review with sip then so be > it. > >> 3) ISSUE: Section 8 - Extended DNS Error Code >> The phrasing here, for both the section title and the content, is odd >> and confusing. For clarity and consistency with section 7, I suggest a >> title of "New Extended DNS Error Code Definition". >> And then the body could start with: "This document defines the >> following >> new IANA-registered Extended DNS Error Code." The existing text will >> then require some tweaking to align with this rephrasing. >> And then to avoid confusion, perhaps change the title of section >> 11.4 to >> "New Extended DNS Error Code Registration". >> No, the section title and its body is consistent with the sections in RFC >> 8914 defining Extended DNS Error Codes, please see >> https://datatracker.ietf.org/doc/html/rfc8914#section-4 >> <https://datatracker.ietf.org/doc/html/rfc8914#section-4> > > OK, I see why you want to phrase these this way. But it doesn't read the same > way here as in rfc8914. This is because rfc8914 has comparable definitions as > subsections of section 4 titled "Defined Extended DNS Errors", which gives > context. > > You could create a similar structure to provide the context. E.g., > > 8. New Extended DNS Errors > > This document defines an addition to the EDE codes defined in > [RFC8914]. > > 8.1 Extended DNS Error Code TBA1 - Blocked by Upstream DNS Server > > ... > > I realize it looks a little odd to have a section with only one subsection, > but it does make the document easier to follow. > >> 6) ISSUE: Section 11.2 - New Registry for Contact URI Scheme >> Could you please add some text describing the role and responsibilities >> of the Change Controller? What sort of changes are allowed? More than >> additions? >> IETF review is required to update the registry, see >> https://datatracker.ietf.org/doc/html/rfc8126#section-4.8 >> <https://datatracker.ietf.org/doc/html/rfc8126#section-4.8>, change >> controller is IETF. > > I think you are missing my point. I'm looking for a more in-depth definition > of the role of "Change Controller". I checked, and this term is currently not > used in Domain Name System (DNS) Parameters. > > I just realized that your definitions of new IANA registries fail to specify > Registration Procedures, which is required. I think you can achieve what you > want by specifying that the Registration Procedure is "IETF Review", > "Standards Action", or "IESG Approval". Then you can omit all mention of > Change Controller. > >> 7) ISSUE: Section 11.3 - New Registry for DNS SubError Code... >> Also, again, could you please add some text describing the role and >> responsibilities of the Change Controller? What sort of changes are >> allowed? More than additions? > > See above. > > Thanks, > Paul > > _______________________________________________ > art mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
