Opened 11 years ago

#8 new defect

It's not clear when a Proxy should/should-not add H-I for "internal" stuff

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

Description

Section 5.1 says:

Retargeting is an iterative process, i.e., a proxy may redirect
"internally " more than one time. A typical example would be a proxy
that redirects a request first to a different user (i.e., it maps to
a different AOR), and then forwards to a registered contact bound to
that new AOR. A proxy that uses such mechanism SHOULD add multiple
hi-entry fields (e.g., bob@… to office@… to
office@192.0.2.5) to provide a logical description of the retargeting
process.

This isn't clear enough. Let's suppose you have an "alias", like john.smith@…, but your real registered AoR is jsmith@…. When the proxy receives a request for john.smith@…, it looks up the location service database and ultimately gets a registered contact for jsmith@…. In some architectures, the proxy would internally go from john.smith@… to jsmith@…, and then to the registered contact. So does it add a H-I for jsmith@…?

The answer matters - both because it impacts the use-case rules described in the use-cases draft, and because it means a UA will get two different sets of H-I entries depending on the internal implementation of the proxy+location-service it uses.

Change History (0)

Note: See TracTickets for help on using tickets.