Alan Johnston wrote:
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.
Alan: That vestige from rfc2543 still persists. The original
header fields in rfc2543 that had a one-letter equivalent
(Call-ID/i, Contact/m, From/f, Content-Encoding/e, etc.) still
persist in the rfc3261 ABNF.
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.
Sure.
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.
OK.
If you feel message size is a problem with this header field, we could
include text suggesting TCP transport be used.
No, I don't think we need to do that. I just wanted to ensure
that you had evaluated the alternative of using a shorter string
and had decided to disregard it because of certain drawbacks. The
two you give above are good trade-offs.
That said, the revised draft is good to go.
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web: http://ect.bell-labs.com/who/vkg/
_______________________________________________
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
