Francois, More below. I have stripped out the comments that have been satisfactorily dealt with.
John > > > 6. In 4.1 "If a UAS does not wish to be reached with a SIPS > > URI but only with a > > SIP URI, it SHOULD respond with a 418 (SIPS Not Allowed)." > > If the UA does not wish to be reached with a SIPS URI, then > > surely it would not register a SIPS contact. If the UA has > > not registered a SIPS contact, it should not normally receive > > a SIPS request. So presumably this is required only for > > requests reaching the UA without going through the domain > > proxy. Correct? If so, perhaps some explanation is needed. > > The main use case is for endpoints that don't register (e.g., > gateways). Furthermore, this is written from the UA point of view > and thus it could happen in error scenarios. > > I'm not sure explaining this will help, but I can add it if > the groups feels it is necessary (I personally think it will just > make the text even more heavy). [JRE] OK, I can live with that. > > > 7. "UAS that > > do not support the SIPS URI scheme altogether "SHOULD reject the > > request with a 416 (Unsupported URI scheme) response" as > > described in > > [RFC3261]/8.2.2.1." > > Similar - should explain how this can occur. > > Same as above. [JRE] Ditto. > > > 8. In 4.1.1 "If a UA registers with a SIPS Contact header > > field, the registrar > > returning a service route [RFC3608] MUST return a service route > > consisting of SIP URIs if the intent of the registrar is to allow > > both SIP and SIPS to be used in requests sent by that > client. If a > > UA registers with a SIPS Contact header field, the registrar > > returning a service route MUST return a service route > consisting of > > SIPS URIs if the intent of the registrar is to allow > only SIPS URIs > > to be used in requests sent by that UA." > > Because 4.1.1 is part of 4.1, which deals only with UAs, then > > it should not contain normative requirements on registrars. > > Presumably the intention of this is to state that RFC 3608 > > places such a requirement on registrars. The language needs > > changing to reflect this. > > Actually, Registrars are "a special type of UAS" according to RFC 3261 > p. 56. This is why it's in this section. [JRE] OK, I don't like it, but I suppose you are correct. However, you didn't respond to the second part of my comment, concerning the need for a change of language. Thinking about this further, I now see that we are in fact updating RFC 3608 - correct? If so, then don't we need to state this up front, and also mention it in the Introduction section where we mention RFC 3261? > > > 11. In 4.2 "It is RECOMMENDED to use an outbound proxy as per > > the procedures > > defined in [I-D.ietf-sip-outbound] for supporting UACs > that can not > > provide a certificate for establishing a TLS connection > (i.e., when > > server-side authentication is used)." > > This is a recommendation on a UA, not a proxy, so it does not > > belong as a normative statement in 4.2. > > I'm not sure I agree on this. Seems like the decision to use > or not the > procedures of sip-outbound in a proxy is a proxy requirement, > not a UA > requirement. [JRE] The words "It is RECOMMENDED to use an outbound proxy" sound to me like a recommendation on a UA, i.e., a recommendation that the UA be configured to use an outbound proxy. Perhaps what we are trying to say is "It is RECOMMENDED that a proxy be able to behave as an outbound proxy as per the procedures...", in which case it would indeed belong in this section. > > > 13. "When a redirect server receives a request with a SIP > > Request-URI, the > > redirect server MAY redirect with a 3XX response to either > > a SIP or a > > SIPS Contact header field. If the target UAS had registered > > previously using a SIPS Contact header field, the redirect server > > SHOULD return a SIPS Contact header field if it is in an > > environment > > where TLS is usable (as described in the previous paragraph)." > > This assumes that a redirect server is redirecting directly > > to a UA, i.e., to a contact. However, a redirect server can > > also redirect to another AoR that resolves to a domain proxy > > (or another redirect server). In other words, the redirect > > server may not have any knowledge of a "target UAS". [JRE] You didn't answer this or make any changes. Do you consider that no change is necessary? _______________________________________________ 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
