Vijay,
Thanks for bringing this up - I meant to respond on the list to the
comment. See below.
Thanks,
Alan
Vijay K. Gurbani wrote:
Mary Barnes wrote:
This email is intended to announce the WGLC review for the following
document:
<http://www.ietf.org/internet-drafts/draft-johnston-sipping-cc-uui-07.txt>
The intent of this review is to determine the completeness of the
problem statement and requirements (per SIPPING WG charter) and
readiness to propose that the solution be worked in SIP WG - with the
obvious understanding that SIP WG must go through the process of
taking on a new work item. In particular we ask that the past
reviewers (Vijay Gurbani, Keith Drage, Laura Liess and Spencer
Dawkins) ensure that their previous concerns and comments have been
adequately addressed in this revision.
Alan, Laura:
I note that all of my comments were adequately addressed except
number 2 and 6 (for a list of my comments, please see
http://www.softarmor.com/sipping/process/wg-review/reviews/draft-johnston-sipping-cc-uui-06-gurbani.txt).
Regarding 2, I suspect that you have adequate reason for not
including this in the Appendix, so I will trust your judgment
here.
Regarding 6, any special reason why a shorter mnemonic of "UUI"
was not included as an alternative?
The only SIP header fields that I'm aware of that allow multiple
encodings are the original RFC 2543 header fields which included the
single character lower case short form. I recall that we discontinued
this because it was felt to be of minimal value in reducing SIP message
size, while at the same time increasing the complexity of parsers and
doubling the number of test cases needed to exercise the protocol.
Besides this, there are two reasons why we chose to not to change the
header field name. One is that the header field contents can be up to
129 octets of data, which would result in the entire header field and
contents adding up to 284 octets to a SIP message. Saving 9 octets or
about 3% doesn't seem to be extremely useful.
The other is that there are already multiple interoperable
implementations that use the current header field, so we'd need a good
reason to change it.
If you feel message size is a problem with this header field, we could
include text suggesting TCP transport be used.
Other than that, I think the draft is ready to go.
Thanks,
- vijay
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
