[Sipping] P-Served-User contents

[Rocío Collado <[e-mail]>]

Hi, all!!


	After having read I-D draft-vanelburg-sipping-served-user-07.txt
there is something unclear to me:

Where are the P-Served-User header field contents extracted from? (in
particular, in the session establishment procedure)

Is this header field filled in with some other header value (Request-URI,
P-Asserted-Id...)? Is perhaps the value taken from some previously stored
information (from registration or subscription procedure)? Does it depend on
the scenario? Do the S-CSCF and the AS extract it from the same origin?

	Thank you very much for your help!!


Rocío Collado Collado
eXperience Ingeniería y Servicios - Boecillo
Tlf.:     983 54 98 48
Móvil: 659 74 57 91
[e-mail]

-----Mensaje original-----
De: [e-mail] [mailto:[e-mail]] En nombre de
DRAGE, Keith (Keith)
Enviado el: jueves, 18 de septiembre de 2008 19:51
Para: Paul Kyzivat; sipping
Asunto: Re: [Sipping] I-D Action:draft-vanelburg-sipping-served-user-07.txt

Paul wrote:

> >  o The next hop proxy supports the P-Served-User header.	
> >  o The next hop proxy requires the served user information
> >    for its proper operation.	
> 
> I don't know how you can know these things. Are these really 
> important to know? Does it hurt anything to insert the header 
> without knowing this?
>

The normal way of dealing with this is that if the next hop does not
support the header, it is configured to not form part of the same trust
domain, and therefore it would be removed by those rules.

That I believe is consistent with your final comment, and indeed has the
same effect.

It is also the way we've defined it is defined in IMS (I think)!

Keith



> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Paul Kyzivat
> Sent: Monday, September 08, 2008 11:37 PM
> To: sipping
> Subject: Re: [Sipping] I-D 
> Action:draft-vanelburg-sipping-served-user-07.txt
> 
> I haven't looked at this since version -00. Compared to that, 
> this is much improved.
> 
> This is clearly very focused for IMS usage, and not 
> meaningful in anything much different from that. But it is a 
> P- header, and so that scoping is ok.
> 
> Just a couple of comments:
> 
> Section 7.1 says:
> 
> >  o The next hop proxy is part of the same Trust Domain
> >    for P-Served-User.	
> 
> Its not good to talk about the "next hop proxy". While you 
> can tell the address of the next hop, whether it is a proxy 
> or not is not determinable by examining the address. So I 
> think it is better to simply 
> say: "the next hop is part of the same Trust Domain", etc.	
> 
> >  o The next hop proxy supports the P-Served-User header.	
> >  o The next hop proxy requires the served user information
> >    for its proper operation.	
> 
> I don't know how you can know these things. Are these really 
> important to know? Does it hurt anything to insert the header 
> without knowing this?
> 
> Section 7.2 says:
> 
> > A proxy that supports the header, MUST remove the header 
> from requests 
> > or responses before further
> > forwarding the message.	
> > 				
> > When the next hop might requires served user information, then the 
> > procedure as in Section 7.1 MUST apply before
> > forwarding the message.	
> 
> Combined with 7.1, this means that the strategy for keeping 
> this header from leaking out into the wild is to insert if 
> for exactly one hop, and depend on the recipient to remove 
> it. This puts a dependency on a lot of nodes.
> 
> Wouldn't it be more consistent to treat this more like 
> P-Asserted-Identity? Namely, remove the header when leaving 
> the trust domain. This only requires the last element in the 
> trust domain to remove it.
> 
> For this header there is the added complication that the role 
> can change from originating to terminating without leaving 
> the trust domain. So it would also be necessary to 
> remove/replace the (old) header when changing roles. But it 
> still need only be done by select elements.
> 
> This would mean that one could always insert the header when 
> sending to 
> an AS, without regard for whether the AS supports it or not.	
> 
> 	Thanks,
> 	Paul
> _______________________________________________
> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP 
> Use [e-mail] for questions on current 
> sip Use [e-mail] for new developments of core SIP
> 
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP