Draft: draft-ietf-sip-hitchhikers-guide-03
Reviewer: John Elwell
Review Date: 2007-10-24
Review Deadline: 2007-10-29
Status: WGLC
Summary: This draft is basically ready for publication, but has nits
that should be fixed before publication.
My 42 comments below.
Minor comments:
1. "Any specification that defines an extension to SIP itself, where"
Change to:
"The basic SIP specification, RFC 3261 [ref], and any specification that
defines an extension to SIP itself, where"
2. "Any specification that defines an extension to SDP"
Change to
"The basic SDP specification, RFC 4566 [ref], and any specification that
defines an extension to SDP"
3. RFC 3840 has been classified as a core spec. I am not sure that it
meets the criterion of applying to most calls. Some implementations only
do isfocus, which hardly arises on every call. You may wish to
reconsider this classification.
4. Concerning RFC 4474: "It has seen little deployment so far,
but its importance as a key construct for anti-spam techniques
makes it a core part of the SIP specifications."
It would be worth mentioning its use for future security mechanisms
(e.g., DTLS-SRTP) too:
"It has seen little deployment so far,
but its importance as a key construct for anti-spam techniques and
new security mechanisms
makes it a core part of the SIP specifications."
5. Concerning ICE: "A SIP option tag and
media feature tag RFC XXXX [108] have been defined for use with
ICE."
It is not clear whether [108] is also a core specification.
6. "RFC 4916 [81] defines an extension to SIP that allows a UAC to
determine the identity of the UAS. Due to forwarding and
retargeting services, this may not be the same as the user that
the UAC was originally trying to reach. The mechanism works in
tandem with the SIP identity specification [19] to provide
signatures over the connected party identity."
It is confusing to talk about UAC and UAS here, because even with RFC
4916 it is always the UAC (for that transaction) whose identity is
given. It might also be worth mentioning mid-call usage. Change to:
"RFC 4916 [81] defines an extension to SIP that allows a calling UA to
determine the identity of the final called user (connected user).
Due to forwarding and
retargeting services, this may not be the same as the user that
the caller was originally trying to reach. The mechanism works in
tandem with the SIP identity specification [19] to provide
a signature over the connected party identity. It can also be used
if a party identity changes mid call due to third party call control
actions or PSTN behavior."
7. "RFC 3960
[27] defines some guidelines for handling early media - the
practice of sending media from the called party towards the caller
- prior to acceptance of the call. Early media is generated only
from the PSTN."
This is not true - application servers can generate early media. Suggest
deleting the last sentence and changing the previous sentence as
follows:
"RFC 3960
[27] defines some guidelines for handling early media - the
practice of sending media from the called party or an application
server towards the caller
- prior to acceptance of the call."
8. "RFC 3204, MIME Media Types for ISUP and QSIG Objects (S): RFC 3204
[84] defines MIME objects for representing SS7 signaling messages.
These are carried in the body of SIP messages when SIP-T is used."
Change to:
"RFC 3204, MIME Media Types for ISUP and QSIG Objects (S): RFC 3204
[84] defines MIME objects for representing SS7 and QSIG signaling
messages.
SS7 signaling messages are carried in the body of SIP messages
when SIP-T is used. QSIG signaling messages can be carried in a similar
way."
9. In the PSTN section you may wish to consider adding
"RFC 4497, Interworking between SIP and QSIG (B): RFC 4497 [ref] defines
how to do protocol mapping from QSIG signaling to SIP."
10. Concerning RFC 3323: "Though it
defines numerous privacy services, the only one broadly used is
the one that supports privacy of the P-Asserted-ID header field
[15]."
Suggest changing "numerous" to "several".
11. Concerning RFC 3311: "This method is meant as a means for
updating session information prior to the completion of the
initial INVITE transaction. It was developed primarily to support
RFC 3312 [59]."
It is not limited to use before completion of INVITE, and one use is for
session timer refresh, another is with connected-ID. Change to:
"This method is meant as a means for
updating session information prior to the completion of the
initial INVITE transaction. It can also be used for updating call
information mid-call. It was developed primarily to support
RFC 3312 [59], but has found other uses, including use with RFC
4028 [ref] for session timer refresh and with RFC 4916 [ref] for
connected identity."
12. Because RFC 4916, a core specification, mandates use of UPDATE, RFC
3311 should be considered a core specification.
13. Concerning RFC 4028: "Session
timers introduces a fair bit of complexity for relatively little
gain, and has thus seen little deployment."
I am a little surprised by this statement, but if it is based on
feedback from SIPit then I guess it is OK.
14. Section "Minor Extensions".
Several of these are extensions to mechanisms listed later in the
document, e.g., REFER, pre-conditions. Should the section be moved
further back, e.g., to the end?
15. Concerning RFC 4508: "It is useful for informing the target of the
REFER
about the characteristics of the REFER target."
Terminology is rather confusing: "target of the REFER" and "REFER
target" are supposed to mean different things. Change to:
"It is useful for informing the target of the REFER request
about the characteristics of the intended target of the referred
request."
16. "RFC 3265 defines a basic framework for event notification in SIP.
It
introduces the notion of an event package, which is a collection of
related state and event information. Much of the state and events in
SIP systems have event packages, allowing other entities to learn
about changes in that state."
Although several RFCs are repeated in different sections
(intentionally), in this particular case the text is completely
different from that in the core specs section. Suggest alignment one way
or the other.
17. "RFC XXXX [96] defines a SIP
event package that allows a proxy to notify a user agent about its
desire for the UA to use certain codecs or generally obey certain
media session policies."
Change "proxy" to "policy server".
18. RFC 4458 is missing - any reason?
19. There is mention of several SDP extensions, yet in the section
"Security Mechanisms", there is no mention of RFCs 4567 and 4568.
20. "17. Emergency Services
Emergency services here covers both emergency calling (for example,
911 in the United States), and pre-emption services, which allow
authorized individuals to gain access to network resources in time of
emergency."
In fact the only two RFCs listed relate to pre-emption, not emergency
calling.
Editorial nits:
21. "and implementations
interested in a particular topic often implement"
Change to:
"and implementers
^^^
interested in a particular topic often implement"
22. "The SIP change process [8] defines two types of extensions to SIP.
These are normal extensions and the so-called P-headers (where P
stands for "preliminary", "private", or "proprietary", and the "P-"
prefix is included in the header field name) are meant to be used in
areas of limited applicability."
Change to:
"The SIP change process [8] defines two types of extensions to SIP.
These are normal extensions and the so-called P-headers (where P
stands for "preliminary", "private", or "proprietary", and the "P-"
prefix is included in the header field name), which are meant to be
used in
^^^^^^^
areas of limited applicability."
23. "RFC 3325 [15], which defines the
P-Asserted-ID header field has been widely deployed."
Add comma as follows:
"RFC 3325 [15], which defines the
P-Asserted-ID header field, has been widely deployed."
24. "RFC 4320 [18] formally updates RFC 3261, and
modifies some of the behaviors associated with non-INVITE
transactions. These address some problems found in timeout and
failure cases."
It is not clear what "these" refers to. Suggest change to:
"RFC 4320 [18] formally updates RFC 3261, and
modifies some of the behaviors associated with non-INVITE
transactions. Modifications address some problems found in
timeout and
^^^^^^^^^^^^^^
failure cases."
25. "RFC 4168 [36] defines how
to carry SIP messages over the Stream Control Transmission
Protocol (SCTP)."
Add reference to SCTP itself.
26. "Its primary application was in support of
voicemail services."
What is the reason for the past tense? Can we just change "was" to "is"?
27. "defines a mechanism for learning about changes in conference
state, including group membership."
Change "group membership" to "conference membership".
This occurs twice.
28. "when there are a multiplicity of
security mechanisms"
Change "are" to "is".
29-42 - padding
John
> -----Original Message-----
> From: DRAGE, Keith (Keith) [mailto:[EMAIL PROTECTED]
> Sent: 15 October 2007 09:32
> To: IETF SIP List
> Subject: [Sip] WGLC of draft-ietf-sip-hitchhikers-guide-03
>
> (As WG chair)
>
> This is to announce a working group last call of
>
> http://www.ietf.org/internet-drafts/draft-ietf-sip-hitchhikers
-guide-03.
> txt
>
> I would request comments on this document be made (to list
> and to author
> mentioned in the document) by Monday October 29th 2007.
>
> Please clearly identify the text of the document that is
> being commented
> on, the nature of the comment (NIT, minor technical, major technical,
> etc), and any suggested resolution, even if it is only some
> alternatives.
>
> 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
>
_______________________________________________
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
