Some late WGLC comments on this. Don't think there are any showstoppers
here.
1) I am not seeing the separation of UAC, UAS, and proxy
requirements required by RFC 4485. Please do not write one requirement
covering two of these entities, and ideally separate these requirements
into separate sections. To me this also means separating UAC and
registrar requirements (which for example impacts 4.1.1). The point of
this is to make it easy for an implementor of a particular item of
equipment (e.g. a terminal, or a proxy including a registrar) to clearly
identify their own requirements they have to meet.
2) Section 3.1.3:
In fact, implementations
SHOULD try to establish a TLS connection when using a SIP URI.
Not sure the RFC 2119 language is appropriate here. Surely this should
be covered by more specific RFC 2119 language in section 4.
3) Section 4.1.3:
As a general principle, derived dialogs and transactions MUST NOT
result in an effective downgrading of SIPS to SIP, without the
explicit authorization of the entities involved.
Not sure how we can demonstrate true compliance against this, and
therefore do not believe the RFC 2119 language is appropriate.
4) Section 4.1.4:
Again, the general principle is that
these mechanism SHOULD NOT result in an effective downgrading of SIPS
to SIP, without the proper authorization.
Again, not sure how we can demonstrate true compliance against this, and
therefore do not believe the RFC 2119 language is appropriate.
5) Section 4.2:
Some proxies MAY have policies that prohibits
sending any request over anything but TLS.
In the context, this is just explaining the previous SHOULD. I don't
think the RFC 2119 language is appropriate.
Similarly for this text in the same section:
Some
proxies MAY have a policy of not forwarding at all requests using a
non-SIPS Request-URI if the UAS had registered using a SIPS Contact
header fields.
6) Section 4.2:
The "transport=tls" parameter must not be used by proxies that
conform to this specification.
Is this a restatement of the text in RFC 3261 (in which case I would
prefer quoting the RFC 3261 text) and saying that there is no change
from this:
Note that in the SIPS URI scheme, transport is independent of TLS,
and thus "sips:[EMAIL PROTECTED];transport=tcp" and
"sips:[EMAIL PROTECTED];transport=sctp" are both valid (although
note that UDP is not a valid transport for SIPS). The use of
"transport=tls" has consequently been deprecated, partly because
it was specific to a single hop of the request. This is a change
since RFC 2543.
Or is it a new normative requirement in its own right, in which case the
we need "MUST NOT".
7) Section 5.1:
This response differs from 416 because the UAS or
proxy recognizes the SIPS URI but it is not allowed, and because the
UAC SHOULD NOT retry the request automatically using a SIP URI.
Is this attempting to state (in which case it should be elsewhere):
If a 418 (SIPS Not Allowed) is received, the
UAC SHOULD NOT retry the request automatically using a SIP URI.
Or is it just defining the semantics of the 418 in which case the RFC
2119 language is not appropriate.
8) Section 5.2:
The UAC SHOULD retry the request automatically using a
SIPS URI.
Again not convinced that the RFC 2119 language is appropriate here. This
should be defining the semantics of the response code.
9) Section 7:
For mutual TLS,
it means that one should be very careful that the architecture of the
network is such that connections are made between entities that have
access to each other's certificates. Record-Route [RFC3261] and Path
[RFC3327] are very useful in ensuring that previously established TLS
connections can be re-used. Other mechanisms may also be used in
certain circumstances: for example, using root certificates that are
widely recognized may allow for more easily created TLS connections.
Does this not get covered by the connect-reuse draft, if we ever get
that finished.
NITS:
-----
A) There is significant usage of lower case RFC 2119 language,
particularly "must". I believe it is desirable to avoid this type of
usage if possible, as it only takes a slip of the editor for it to
become a "MUST" and we have a new requirement that was not agreed by the
WG. I think it is possible to find alternatives.
B) There are a number of instances of "it" where I would prefer
"the proxy" or whatever, e.g. in structures such as:
When a proxy inserts a Record-Route entry, it must take care in using
the proper scheme
Should become "the proxy". I don't want people fighting their way back
in the sentence to find the real subject.
And
If the proxy needs to reject the request for
that reason, it MUST reject it with a 418 (SIPS Not Allowed).
Should become:
If the proxy needs to reject the request for
that reason, the proxy MUST reject it with a 418 (SIPS Not Allowed).
C) Ensure that all request names, e.g "REGISTER" are followed by
"request", i.e. "REGISTER request".
D) Section 4.1.2:
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: it MUST only use the SIPS
version in this case.
":" --> ";", and also as in B) above "it" --> "the UA"
E) Capitalisation. "proxy", "redirect server" etc are not proper
nouns, therefore please use lower case initial letters.
F) Section 4.1.2:
If all the Contact header fields in a REGISTER are SIPS, a SIPS AOR
MUST be used by the UAC in the REGISTER. If at least one of the
Contact header fields is SIP or is neither SIP nor SIPS (e.g.,
mailto, tel, http, https), a SIP AOR MUST also be used by the UAC.
Rewrite as
If all the Contact header fields in a REGISTER request are SIPS, a
the UAC
MUST use a SIPS AOR in the REGISTER request. If at least one of the
Contact header fields is SIP or is neither SIP nor SIPS (e.g.,
mailto, tel, http, https), the UAC MUST also use a SIP AOR.
G) Section 4.1.3:
If the top Route header field
does not contain a SIPS URI, the Contact header field MUST be a SIP
URI, even if the request is sent over a secure transport (e.g., the
first hop could be re-using a TLS connection to the proxy as would be
the case with [I-D.ietf-sip-outbound]).
Rewrite to clearly indicate a UAC requirement, ie. "the UAC must..."
H) Section 4.1.4:
If that initial dialog was
established using SIPS, then the new one MUST NOT be established
using SIP, unless there is an explicit authorization given by the
recipient of the REFER.
Rewrite to clearly indicate a UAC requirement, ie. "the UAC must..."
I) Appendix B:
If the address-of-record in the To header field of a REGISTER
request is a SIPS URI, then any Contact header field value in the
request MUST also be SIPS URIs.
Rewrite as UAC requirement:
If the address-of-record in the To header field of a REGISTER
request is a SIPS URI, then the UAC MUST also include only SIPS
URIs in any Contact header field value in the
request.
Regards
Keith
_______________________________________________
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
