Subject: [Sipping] location-requirements-02

From: Cullen Jennings <[email-masked]>
Date: Fri, 05 Nov 2004 21:08:29 -0800

Some of the things I mention below are, in my mind, very hard to solve
without multipart support. I think the WG should consider making multipart
support mandatory. 

If you can put an LO in a 200, what happens if the 200 is too big? Does it
just get silently dropped. Related to this, if the UAC does not support
multipart, and the UAS forms a 200 with a multipart, what happens?

If we go with a proxy forms an error to tell the UAC to insert an LO, then
how does a proxy tell the UAS what LO to put in the answer. If the proxy
rejects calls without an LO (and provides information on how to insert one)
and the UAS does not support multipart, what happens.

The idea that a proxy that fails and attempt the first time must remember
this and allow it the next time does not seem workable to me. I think you
need to get it so that the proxy will not fail things it can not fail. (page
36)

Consider the problem described in the draft where  UA-A sends an INVITE to a
proxy that decides to route it to B, then before their is a dialog formed,
UA-A location changes such that the call would not be routed to C. I think
that in this case, we should just fail this call and try again or just let
the call go to B.

Imagine that A is calling B via proxy-a and proxy-b. I think it is a
requirement that A should be able to reveal it's location to proxy-a but not
to B. I'm not sure I can think of a good reason why. Anyways, sorting out
the the answer to this seems somewhat important. A related case is A routes
to proxy-hotel that goes to proxy-a to B and A wants to reveal location to
proxy-a but not proxy-hotel. U-U2 might need to get a bit more specific on
"confidential" with respect to who.

Paragraph at end of section 2 sounds like a poster child use case for e2m
security. 

The example with putting the two locations in a refer looks really
complicated to get right. Do we need this? Agree it looks possible.

Example 8.2.1 might be better if the text/plain was not encrypted but the LO
was. Glad to help provide text.

Around page 34 - "the second probability in message flows" I think you mean
problem 

_______________________________________________
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: "James M. Polk" <[email-masked]>
Date: Tue, 09 Nov 2004 10:57:56 -0600

>without multipart support. I think the WG should consider making multipart

I will bring this up during the ID presentation (as your idea  ;-)

>just get silently dropped.

We know we cannot error a UAS Response - so this creates a problem. I will 
bring this up in the preso also and see what people say

>Related to this, if the UAC does not support

this is a problem that's not exclusive to location - but this brings it to 
the surface

>how does a proxy tell the UAS what LO to put in the answer.

this isn't specified, it's currently up to Bob

This is an open issue I've had in the doc since non-wg item -00, with no 
resolution

There was talk in San Diego of work coming to address how to request a body 
(hopefully specifying the body type...)

>If the proxy

If the UAS does not support multipart, this issue has been raised and will 
be asked of the group

If the question is about the proxy erroring the UAC if no LO was present 
and the UAS doesn't include an LO, the proxy cannot currently (as stated) 
error a UAS

>this and allow it the next time does not seem workable to me.

Why not? If the Proxy is aware enough to fail for this new reason, why 
can't it be expected to have code addressing the situation that it needs to 
look for a follow-up message that no longer error meets that same error 
condition?

>I think you

don't I state that on page 36 already?

>that in this case, we should just fail this call and try again or just let

I was looking for guidance on this - failing the pending request is 
acceptable. Do you agree that the Proxy sends a CANCEL towards the 
UAS/Proxy, but what 4XX would you send to the UAC that tells it to retry 
immediately? Is this another new 4XX code (I hope not).

>to B. I'm not sure I can think of a good reason why.

Wouldn't this require Proxy-A conceal the body from Proxy-B (middle-2-end 
security)? This will add time to the call set-up in an emergency situation, 
many will not like that, and we should have a discussion about it.

>Anyways, sorting out
>proxy-a but not proxy-hotel.

This is fairly clearly e2m, isn't it? But how does A know about each 
component in the signaling path? And, how does A get Proxy-a's key?

>U-U2 might need to get a bit more specific on

please offer text

>Paragraph at end of section 2 sounds like a poster child use case for e2m

ok

>complicated to get right. Do we need this?

the longer it's in the doc, the more complicated it looks - so I'm leaning 
towards removing it

>Agree it looks possible.
>was.

good idea

>Glad to help provide text.

please

>Around page 34 - "the second probability in message flows" I think you mean

yep

cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented