These address my comments. Thanks!
RjS
On Jun 17, 2007, at 6:15 AM, Gonzalo Camarillo wrote:
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
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
