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."
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.
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.
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
