Subject: RE: [Sipping] draft on SIP architectural principles

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 2 Mar 2005 15:28:07 -0500

Brian,

Limiting to headers would be too restrictive.  
Use the SIP-T ISUP-based MIME body as a case in point.

Mike 

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Brian Rosen
>Sent: Wednesday, March 02, 2005 10:26 AM
>To: Jonathan Rosenberg (jdrosen); 'sipping'
>Subject: RE: [Sipping] draft on SIP architectural principles
>
>I like this draft.
>
>The only technical issue I thought of when reading is in:
>   That said, the specifications do not prohibit proxies from invoking
>   special routing logic based on method or other information in the
>   message.  Such behaviors are typical of distributed proxy networks
>   where the overall processing of a SIP user agent is distributed
>   across multiple components, and a proxy is used to route messages to
>   the appropriate component.
>
>The problem is with the phrase "other information in the message".
>If you had said "other information in the headers" I would 
>have no problem.  By saying "in the message", you sanction 
>examining the SDP, and thus run afoul of SMIME encryption.
>
>I noticed a few nits other than "wrong at once"
>Section 3.2 "use a button the remote to indicate" missing an "on"
>Section 3.4 "Of course, if the endpoints fail, the call is 
>over even in any case" probably doesn't need the word "even"
>Section 3.8 "SIP has not tried to parsimonious in its" missing a "be"
>Section 4.3 "Genreally speaking" oh really?
>Section 4.9 "including non-SIP URI like the" probably "URIs"
>
>Brian
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On 
>> Behalf Of Jonathan Rosenberg
>> Sent: Wednesday, March 02, 2005 3:06 AM
>> To: sipping
>> Subject: [Sipping] draft on SIP architectural principles
>> 
>> Folks,
>> 
>> I wanted to call your attention to the following I-D:
>> http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-sip-arch-
>> 00.txt
>> 
>> This is an attempt to summarize some of the key architectural and 
>> design principles that underly SIP. Henning and I would welcome 
>> comments and suggestions for additional principles.
>> 
>> Thanks,
>> Jonathan R.
>> --
>> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
>> Director, Service Provider VoIP Architecture   Parsippany, 
>NJ 07054-2711
>> Cisco Systems
>> [email-masked]                              FAX:   (973) 952-5050
>> http://www.jdrosen.net                         PHONE: (973) 952-5000
>> http://www.cisco.com
>> 
>> _______________________________________________
>> 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
>> 
>
>
>
>
>_______________________________________________
>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
>

_______________________________________________
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: "Brian Rosen" <[email-masked]>
Date: Wed, 2 Mar 2005 15:52:59 -0500

I'm sorry, but we HAVE to allow encryption of the body end to end, and that
includes SIP-T.  It's pretty unusual to have a proxy server route on the
ISUP body, and it just doesn't work if the proxy can't decrypt it.

Brian

> From: Michael Hammer (mhammer) [mailto:[email-masked]]
> Sent: Wednesday, March 02, 2005 3:28 PM
> To: Brian Rosen; Jonathan Rosenberg (jdrosen); sipping

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 3 Mar 2005 10:00:06 -0500

I observe that my own work violates this :(
If you need to route on location, and location is carried in a body, you
better not SMIME encrypt the location.

In this case, the sender knows he wants to route the call based on location.

You probably could make the same argument for other things.
The general case is still true; assume SMIME of bodies.

Brian

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Brian Rosen
> Sent: Wednesday, March 02, 2005 3:53 PM
> To: 'Michael Hammer (mhammer)'; 'Jonathan Rosenberg (jdrosen)'; 'sipping'

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 04 Mar 2005 21:20:39 -0800

> In this case, the sender knows he wants to route the call based on location.

ok, this is off the wall but, perhaps location should be in a header. We
have this fascinations with big things are bodies small things are headers
but the message is going to be the same size either way. I'm actually in
favor of it being a body specifically so that Identity will provide
integrity across it but it does make me wonder if a body is the only choice.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 05 Mar 2005 09:36:11 -0500

> integrity across it but it does make me wonder if a body is the only choice.

Headers would indeed make many things easier, if only because they can 
be inserted by proxies. (Location information, at least initially, will 
often be known only by the service provider.)

Location information itself isn't long - you can probably encode geo 
location in about 10 characters and postal/civic addresses in the US are 
guaranteed to be no longer than (I think) 60 characters. Obviously, this 
is without ten layers of XML namespace declarations.

I believe Geopriv is looking at HTTP location headers.

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 7 Mar 2005 08:26:54 -0500

I think I'll let James respond to this, just as soon as the steam stops
rising from his head.

Suffice it to say that this idea has been debated, for a long time, and it's
a body, get over it.

Brian

> From: Cullen Jennings [mailto:[email-masked]]
> Sent: Saturday, March 05, 2005 12:21 AM
> To: Brian Rosen; Michael P Hammer; Jonathan Rosenberg; sipping
> Subject: Re: [Sipping] draft on SIP architectural principles
>

---

From: David R Oran <[email-masked]>
Date: Mon, 7 Mar 2005 08:55:18 -0500

I've always wondered why we didn't simply have BOTH. They serve 
different purposes and have different security considerations too.

>> integrity across it but it does make me wonder if a body is the only
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 7 Mar 2005 09:03:29 -0500

I'd sign up for that.  It would fix a lot of problems.

Brian

> From: David R Oran [mailto:[email-masked]]
> Sent: Monday, March 07, 2005 8:55 AM
> To: Brian Rosen
> Cc: 'Cullen Jennings'; 'Michael P Hammer'; 'Jonathan Rosenberg'; 'sipping'