Hi Robert,
thanks for your comments. Answers inline:
Robert Sparks wrote:
I have been selected as the General Area Review Team (Gen-ART) reviewer
for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-rohc-sigcomp-sip-06.txt
Reviewer: Robert Sparks
Review Date: 5/30/07
IETF LC End Date: 5/29/07
IESG Telechat date: (if known) 6/7/07
Summary: This draft is ready for publication as a Proposed Standard RFC.
There are some small nits the submitters and IESG
may wish to
consider addressing before publication.
Comments:
1) Section 8 mislead me (an experienced person in these technologies)
into misinterpreting
what it was saying. My misinterpretation was that it was
preventing SIP retransmissions. Its
intent was to note that any retransmission had to be
recompressed, that it was not valid to
cache a previous compression and retransmit that. The following
text was suggested as
a replacement:
"When SIP messages are retransmitted, they need to be re-compressed,
taking into account any SigComp states that may have been created or
invalidated since the previous transmission. Implementations MUST
NOT cache the result of compressing the message and retransmit such
a cached result."
OK, I will perform the following change:
OLD:
SIP retransmissions need to be compressed again before being sent.
That is, SIP applications MUST NOT retransmit already-compressed
information.
NEW:
When SIP messages are retransmitted, they need to be re-compressed,
taking into account any SigComp states that may have been created or
invalidated since the previous transmission. Implementations MUST
NOT cache the result of compressing the message and retransmit such
a cached result.
2) 9.4 discusses drawbacks of stateless compression and states that
if a compartment is not available, that the application MAY choose
not to compress a given message (putting some non-normative pressure
on applications to choose not to do so). Section 5, however
notes that
you cannot mix SIP messages and SigComp messages on any given
TCP stream and calls out a null decompression algorithm to use to
effectively send a "compressed" message that isn't compressed. I
think
section 9.4 should explicitly call back to this this case to help
avoid
implementor confusion.
Would the following change address your comment?
OLD:
The use of stateless compression (i.e., compression without a
compartment) is not typically worthwhile and may even result in
message expansion. Therefore, if a SIP application does not have a
compartment for a message it needs to send, it MAY choose not to
compress it even in the presence of the comp=sigcomp parameter.
OLD:
The use of stateless compression (i.e., compression without a
compartment) is not typically worthwhile and may even result in
message expansion. Therefore, if a SIP application does not have a
compartment for a message it needs to send, it MAY choose not to
compress it even in the presence of the comp=sigcomp parameter.
Section 5 describes how a SIP application can send compressed and
uncompressed messages over the same TCP connection.
3) I have personal heartburn with the decision in the document to scope
the use of SigComp in SIP to only those cases where registration
state
is being maintained. There is no way for endpoints that, for
instance, only
publish or subscribe to use SigComp the way this document is
written.
That said, there is real complexity in providing a mechanism that
works
outside a context like registration, and there is, per the
submitters, working
group consensus around this restriction. I suggest adding a
paragraph
explicitly calling out this restriction and briefly discussing
why the group
decided to accept it.
We can perform the following change in Section 9.3:
OLD:
Previous revisions of this document also defined compartments
valid during a SIP transaction or a SIP dialog. It was decided to
eliminate those types of compartments because the complexity they
introduced was higher than the benefits they brought in most
deployment scenarios.
NEW:
Note that linking the lifetime of SIP/SigComp compartments to
registration state limits the applicability of this specification. In
particular, SIP user agents that do not register but, for example,
only handle PUBLISH or SUBSCRIBE/NOTIFY transactions are not able
create SIP/SigComp compartments following this specification. Previous
revisions of this specification also defined compartments valid during
a SIP transaction or a SIP dialog. Those compartments covered all
possible SIP entities, including those that do not handle REGISTER
transactions. However, it was decided to eliminate those types of
compartments because the complexity they introduced (e.g., edge proxy
servers were required to keep dialog state) was higher than the
benefits they brought in most deployment scenarios.
Additionally, per Adam's request, I intend to add the following
clarification to the last paragraph of Section 9.3:
OLD:
If, following the rules above, a SIP application is supposed to open
a compartment for a remote application identifier for which it
already has a compartment, the SIP application MUST use the already
existing compartment. That is, the SIP application MUST NOT open a
new compartment.
NEW:
If, following the rules above, a SIP application is supposed to open
a compartment for a remote application identifier for which it
already has a compartment (e.g., the SIP application registers
towards a second registrar using the same edge proxy server as for
its registration towards its first registrar), the SIP application
MUST use the already existing compartment. That is, the SIP
application MUST NOT open a new compartment.
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
