Subject: [Sipping] RE: Continuing review of draft-ejzak-sipping-p-em-auth now -01

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Sun, 25 Jun 2006 11:37:06 -0500

Hi Paul,
Thanks for your review.

There are any number of different policies that a network may implement with the header, so I don't see the value in including an interop section.  The behavior at an endpoint will depend completely on the policy chosen and there is no desire to mandate any particular policy in the draft.  That's why there are so many MAYs in it.  If you want the draft to say that depending on the local policy chosen there may be cases where early media will not be available to an endpoint - well that's pretty redundant, isn't it?

Gonzalo has also requested that I limit discussion of particular policies, which I have tried to do.

Certainly one possible policy is to authorize all early media from a particular peer network, regardless of the presence of the header in messages from that network (note that a boundary proxy can add the header).  A good example of this is when the peer network is a SIP-I network that always uses early media.  So the answer to your question is "yes" and an informational RFC should be adequate.

Richard

Paul Kyzivat wrote:
> I just got to looking at the new version. It has cleaned up a 
> number of 
> things, and I find it improved because it is more up front 
> about early 
> media gating.
> 
> I still think there are major interoperability problems with 
> implementations that don't understand this header. I would 
> like to see 
> an interop section in the document that investigates cases where only 
> the calling side, or only the called side understands the 
> header and is 
> within the trust domain. I think that will bring to light issues that 
> should be confronted.
> 
> The basic issue here is whether there can ever be an expectation that 
> early media works in the absence of an extension like this. If the 
> answer is "no" then this should probably be standards track 
> rather than 
> a P-header.
> 
> 	Paul
> 

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

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 25 Jun 2006 14:45:52 -0400

Richard,

As best I can tell, there are only a few reasons for this draft and header:

- to provide a new mechanism for a UA to use when deciding whether
   to render early media it receives

- to provide a mechanism for a UA to indicate it intends to send
   early media

- to provide a mechanism for middle boxes to indicate that early
   media is being denied

Without this, there is already a mechanism for a UA to use to decide to 
render early media: It should just render what it receives. Introducing 
another mechanism for this seems certain to present interop problems.

Without this there is no expectation that a UA needs to explicitly 
indicate its intent to use early media. Introducing a mechanism for this 
seems certain to present interop problems.

The use by middleboxes is a second order issue, because if the middlebox 
is blocking early media then it will cause interop problems whether this 
new mechanism is used or not. But the mechanism is a surrogate for 
approving of this blocking.

The interop issues are the same regardless of what policy is used, 
(except for a policy that says not to use the header). So I think the 
interop scenarios can be worked out in a policy independent manner, and 
without regard for what middleboxes do to the header. I think the cases 
are simply based one end (UAC or UAS) using / expecting use of the 
header together with the value used, and the other end not understanding 
or using the header.

For instance, if the UAC will only render early media if the header is 
present, while the UAS sends early media without including the header, 
then there will be an interop problem. IMO this is the kind of result 
that is not supposed to happen with P-headers. (But that is a complex 
subject and don't pretend to be the authority for making that call.)

	Paul