Opened 11 years ago

Last modified 10 years ago

#12 new enhancement

Section 7 on Application Considerations needs work

Reported by: hkaplan@… Owned by:
Priority: major Milestone: milestone1
Component: rfc4244bis Version: 2.0
Severity: In WG Last Call Keywords:
Cc:

Description

The thing I fear the most about H-I is that different UAS will process this thing and expect to see things a certain way, and applications will fail when they don't, and SBC vendors will once again be fixing the headers to make interop work.

In that sense, I think Section 7 may be the most important section to get right. In particular, items 2, 4 and 5 in this section are not necessarily true. I will submit separate tickets on them.

This ticket is for asking for additional text such as:
"Implementers should make certain their applications do not expect specific H-I entries or index values to contain the information they need, because SIP requests may follow numerous paths with multiple request-URI rewriting cases in different deployments. For example, there may be multiple "rc" entries due to forking, or multiple entries which are neither "rc" nor "mp" entries due to normal routing, or multiple "mp" entries due to multiple diverts. H-I entries can be non-SIP URIs, such as TEL URIs. Furthermore, H-I entry URIs may contain both URI parameters and URI user parameters which are unknown to the final UAS, which MUST be ignored for the purposes of identity matching."

Change History (1)

comment:1 Changed 10 years ago by worley@…

Indeed, section 7 should present sample (not normative) algorithms that particular applications might use, to show that the 4244bis mechanism actually does support the applications that people want.

Note: See TracTickets for help on using tickets.