Subject: [Sip] SIPit 20 survey summary

From: Robert Sparks <[email-masked]>
Date: Thu, 26 Apr 2007 10:34:36 -0500

SIPit 20 was hosted by Alcatel-Lucent in Antwerp, Belgium from April  
16 to April 20, 2007. Many thanks to Alcatel-Lucent, in particular  
Ben Bonnaerens and Nadine Staelens for a well-planned and effective  
event in a very nice venue.

There were 145 attendees from 59 companies visiting from 19 countries  
present.
There were 67 teams and around 90 distinct implementations.

A higher than usual percentage of the attendees (my guess is around  
60%) were attending SIPit for the first time.

The most common thread in interoperability problems centered on  
interpreting SDP at this event. Most of these were implementation  
issues, but more people are running into issues as they try to  
exchange more than the most basic of offers and answers. These ranged  
from issues with multiple m-lines to trying to specify different  
packetization times for codecs on the same m-line to problems with  
the "delayed" offer-answer exchange in INVITE/200/ACK (where the  
INVITE has no body).
More implementations are supporting TLS, and several implementations  
had issues  around correctly handling mutual authentications and  
reusing connections.

There was a lot of (understandable) confusion about what to do with  
sips:. Most implementations that could handle TLS are not yet trying  
to handle sips:. The few that did try to do something sane with sips:  
are watching the discussion on the SIP mailing list. In any case,  
there was not a set of implementors present who felt sips was  
sufficiently specified and would be unhappy if the definition  
changed. I also didn't find anyone who felt an existing deployment  
would suffer from any change to the definition.

We used a web-based survey tool for collecting implementation  
statistics for the second time. As noted in the report for SIPit19,  
this has an impact on the accuracy of the information (since someone  
will inevitably not understand one or more questions, or won't know  
the answer). Only 59 of the 67 teams completed the survey. We plan to  
use a slightly different mechanism at the next event to improve the  
accuracy and completeness of the results.

With the understanding that there is some sampling error here is what  
those 59 teams reported:

The roles represented (some implementations act in more than one role):
   29 endpoints
   19 proxy/registrars
    5 standalone proxies
    5 redirect servers
    7 gateways
    9 automaton UAs (voicemail, conference, etc.)
   17 b2bua/sbcs
    5 UAs with signaling but no media
    4 test/monitoring tools

Implementations using each transport for SIP messages:
   UDP 100%
   TCP  82%
   TLS  46% (server auth only)
   TLS  24% (server or mutual auth)
   SCTP  7%
   DTLS  0%

71% of the implementations claimed they would correctly reassemble  
fragmented UDP (10% of the remaining were not sure).

At SIPit19, I asked for the size of the largest datagram an  
implementation would accept. The answers indicated that most folks  
didn't understand the question, so I was not able to produce a useful  
summary from that event. We repeated the question at SIPit 20, and  
while there's still confusion, there are enough answers to start  
getting a picture. Remember again that these are self-reported numbers:
    1500 bytes or less: 18% (the smallest was 1300)
    1500 to 4K        : 10%
    64K               : 24%
    didn't know       : 25%
25% of the implementations present supported SIP over IPv6.

For DNS we had support for:
    Full RFC3263    : 54%
    SRV only        : 14%
    A records only  : 14%
    no DNS support  : 12%
    other           : 6% (includes those that didn't know or didn't  
reply)

Support for various items:
    31% ENUM
    68% rport
    27% multiplexing SIP/STUN on the same port
    14% SIGCOMP
    15% RFC4320 fixes
    16% Identity

There were no implementations present of any significant part of the  
session-policy framework.

There were no implementations of the hilt-sipping-*-overload drafts  
or anything else meeting the requirements in ietf-sipping-overload-reqs.

There were two server implementations of sip-outbound, but no clients  
to test against.

There were 4 implementations of GRUU present (at different draft  
levels). We did have one successful test where a UA obtained and used  
a GRUU.

The endpoints implemented these methods:
    100% INVITE, CANCEL, ACK, BYE
     94% REGISTER
     92% OPTIONS
     79% SUBSCRIBE <- Notice the difference here...
     96% NOTIFY    <-    unsolicited notifies were prevalent
     68% PRACK
     58% MESSAGE
     79% INFO
     64% UPDATE
     87% REFER
     38% PUBLISH

The endpoints implemented these extensions:
   77% RFC3891: replaces
   60% RFC4028: session-timer
   21% RFC3327: path
    6% RFC3840: pref
    2% RFC3841: caller-prefs
   30% RFC3323: privacy
    0% RFC4538: target-dialog
    6% RFC4488: norefersub
   68% RFC3262: 100rel
   11% RFC3994: indication of message composition

57% of the endpoints implemented sipping-cc-transfer

When asked about STUN support, the client implementations replied:
    8% I implement all the client requirements of draft-ietf-behave- 
rfc3489bis
    6% I implement some, but not all, of the client requirements of  
draft-ietf-behave-rfc3498bis
    4% I implement all of the client requirements of RFC3489
   14% I implement some, but not all, of the client requirements of  
RFC3489
   60% I do not implement STUN as a client
    8% Other

There were several STUN servers and at least two TURN servers. We had  
more TURN clients this time, and successfully exercised TURN. Three  
implementations claimed support for ICE, but no interoperability was  
reported (I suspect there were versioning issues that couldn't be  
overcome in the time-scale of the event). There was one ice-tcp  
implementation present.

This is how the endpoints characterized their handling of S/MIME:
    6% I break if someone sends me S/MIME
   34% I pretend S/MIME doesn't exist if it shows up
   38% I don't pay attention to S/MIME, but will proxy it or hand it  
to my application
    4% I pay attention to S/MIME I receive, but don't send any
    0% I don't pay attention to S/MIME I receive, but I do send some
    6% I try to do something useful with S/MIME I receive and send
   12% Other

This is how they answered for multipart/mime:
    2% I break if someone sends me multipart/mime
   24% I pretend multipart/mime doesn't exist if someone sends it to me
   24% I ignore multipart/mime but will proxy it or hand it to my  
application if it shows up
   10% I try to do something useful with multipart/mime I receive,  
but I never send it
    4% I ignore multipart/mime that I receive, but I try to do  
something useful with multipart/mime I send
   24% I try to do something useful with multipart/mime I send and  
receive
   12% Other

Here is how the endpoints claimed to handle receiving 200 OKs from  
more than one branch of a forked INVITE:
   36% I send BYEs to all but one branch
   10% I use all of them (perhaps mixing the different media streams  
locally)
   42% I don't handle this case gracefully
   12% Other

27% of the endpoints did not use symmetric RTP

This is how the endpoints (that actually handled media) described  
their use of RTCP:
   33% I fully implement RTCP and use the RTCP from my peers
   27% I send some RTCP, and open a port to receive RTCP, but I  
ignore any packets I receive
    6% I never send RTCP, but I do open a port for receiving (and  
ignoring) it
   34% I don't even open a port for RTCP

There were 9 SRTP endpoints (down from 12 at the last event). Only 4  
of those used sdes.
Interoperability after key exchange was lower than at SIPit 19.
There was only one RTP over DTLS implementation present.

One endpoint claimed support for comedia (but 10 claimed they would  
send media over TCP).

For hold, the endpoints claimed:
   8%  I don't support hold
   4%  I set the m-line port to 0
10%  I set the c-line to 0.0.0.0
27%  I use the sendonly/recvonly/sendrecv attributes
15%  I use the s/r/sr attributes, but only if I see them in SDP from  
the other party first, otherwise I set the m-line port to zero
17%  I use the s/r/sr attributes AND set the m-line port to 0
19%  I don't do any of those things

25% of the endpoints would offer SDP with more than one m-line.
57% would only play one audio stream if they received multiple.

Most proxies are now doing either 3261 or fork-loop-fix loop detection.

Only 30% of the proxies claimed they would forward a request with an  
unknown RURI scheme when there was a Route header field whose first  
value is a SIP URI.

25% of the proxies actively participate in session timer.

5 of the 19 proxies present would upgrade from sip: to sips: while  
forwarding. 6 would downgrade.

6 of the registrars would allow non-sip or sips schemes in contacts.
6 of the registrars claimed to accept an S/MIME signed or encrypted  
REGISTER request.

Less than half of the b2bua/sbc-like elements could be configured to  
forward unknown methods.
Most could be configured to forward unknown SDP lines.

There were 46 SIP-Events implementations

These were the supported event packages:
30 refer
20 message-summary
14 presence
14 dialog
   9 reg
   6 conference
   2 ua-profile
   2 gruu-reg-event
   2 kpml

5 supported winfo

4 supported event-list

15 would issue an unsolicited NOTIFY.
27 would respond to an unsolicited NOTIFY with a 200-OK

There were 2 partial-publish/partial-notify implementations

4 implementations supported presence-rules

I repeated the question about which P-headers each implementation  
actively supported:
   34 P-Asserted-Identity
   21 P-Preferred-Identity
   12 P-Associated-URI
   12 P-Called-Party-ID
   10 P-Access-Network-Info
    8 P-Charging-Vector
    7 P-Visited-Network-ID
    7 P-Charging-Function-Address
    5 P-Media-Authorization
    4 P-User-Database
    4 P-DCS-* (andy of the P-DCS headers)
    1 P-Answer-State

Let me know if there are other questions you'd like to see asked next  
time.

RjS

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

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 27 Apr 2007 14:48:15 -0400

>    24% I try to do something useful with multipart/mime I send and

Moving forward, SIP UAs and proxies will be required to support
location-conveyance (currently draft-ietf-sip-location-conveyance-07) in
order to support location for emergency calls (citizen to authority, like
1-1-2 or
9-1-1).  -conveyance requires multipart support.  

The consequences of not supporting emergency call location will be serious.
I believe it is likely that there will eventually be regulatory requirements
to support emergency calls in some jurisdictions.  Upgrades to several
components of today's infrastructure will be needed before this all works,
but stack vendors and UA developers should put multipart (and
location-conveyance) on their development plans for next year at the latest.

Brian

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sat, 28 Apr 2007 11:19:50 +0200

A point for discussion: I believe below is evidence that the complexity of 
implementation may hinder deployment of emergency services, and may even be 
a root cause of things breaking down at a critical moment. People's lives 
may depend on a proxy interpreting location information properly

Especially for the use case of emergency calls, would it not be wise to 
select a much more simple approach/syntax, e.g.:
Emergency-Location: lat=x; lon=y

So no XML, no mime/multipart, as simple as possible (no complex semantics, 
usage-rules etc), something to reduce the barrier of 
implementation/deployment, and to reduce the risk for interop issues?

Regards,
Jeroen

Brian Rosen wrote:
>>    24% I pretend multipart/mime doesn't exist if someone sends it to
>>    me 24% I ignore multipart/mime but will proxy it or hand it to my
> location-conveyance (currently draft-ietf-sip-location-conveyance-07)
> in order to support location for emergency calls (citizen to
> authority, like 1-1-2 or
> The consequences of not supporting emergency call location will be
> serious. I believe it is likely that there will eventually be
> regulatory requirements to support emergency calls in some
> jurisdictions.  Upgrades to several components of today's
> infrastructure will be needed before this all works, but stack
> vendors and UA developers should put multipart (and

---

From: [email-masked] (Juha Heinanen)
Date: Sat, 28 Apr 2007 12:35:42 +0300

> implementation/deployment, and to reduce the risk for interop issues?

i fully agree with this.  we should follow KISS principle here.  it is
highly unlikely that sip ua vendors will even TRY implement such a
complex protocol.  

another reason why it will not get implemented is that sip uas don't
know where they are located.  gps does not work well indoors and mobile
operators at least here have refused to make public coordinates of their
base stations.

-- juha

---

From: "Frank W. Miller" <[email-masked]>
Date: Sat, 28 Apr 2007 12:04:51 -0600

Amen.

FM

---

From: "Mark R. Lindsey" <[email-masked]>
Date: Sat, 28 Apr 2007 16:13:20 -0400

It is much more reasonable to expect the service-provider/enterprise  
to implement the location conveyance. They'd add the location in  
their proxies/B2BUAs/ALGs. For example, an enterprise building ALG  
could add its location before sending the call to an SP.

(Hah! Another obvious idea made un-patentable.)

In addition, it's the service provider that will likely perform SIP  
peering with a PSAP. In the US, that's the typical model in already.  
Service providers sometimes already know where their users are. Yes,  
yes, I know this isn't the main point of location-conveyance.

But besides all of this: we've got to get the PSAPs capable of  
reliably using the location provided in the call. The capability to  
send the location will be far simpler than actually having a PSAP  
that can accept and use it.

> Emergency-Location: lat=x; lon=y

The location-by-"reference" (i.e., provide a URI to a PIDF-LO instead  
of carrying the document itself) should do what you need here. Many  
UACs already have HTTP servers, which would be compatible with such a  
system, maintain end-to-end privacy requirements. Or the SUBSCRIBE- 
NOTIFY version of PIDF-LO retrieval could easily be implemented with  
a partial multipart-mime implementation, and it could work even  
through proxies.

> operators at least here have refused to make public coordinates of  

Other location-sensing technology may come along, now that there are  
good reasons for it.

Mark R. Lindsey  | ECG |  +1-229-316-0013  |  [email-masked]

---

From: [email-masked] (Juha Heinanen)
Date: Sat, 28 Apr 2007 23:25:16 +0300

> could add its location before sending the call to an SP.

enterprises (at least smaller ones) don't run their own proxies.  they
buy the service hosted and the service provider has no idea where the
individual phones are.  especially now when, for example, nokia
enterprise phones allow you to make calls over 3G or WLANs everywhere.

 > yes, I know this isn't the main point of location-conveyance.

in finland, sweden, and some other european contries the standard for
emergency calls is to prefix emergency number with community code of the
caller.  proxy can do that IF caller always keeps his/her current
community code up to date, which is a big IF.  there is thus no need for
this location conveyance draft.

 > that can accept and use it.

so you have big problem at both ends.  not very motivating for
implementers.

-- juha

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 28 Apr 2007 15:23:24 -0700

There has been an incredible amount of work on this topic across many  
standard organizations including the IETF. Before people start in on  
discussing this in - I strongly suggest they might want to read some  
of the requirements, uses cases, drafts, and mailing list discussions  
in ECRIT and GEOPRIV. Please keep in mind the charters of ECRIT/ 
GEOPRIV/SIP and take the discussion to the right working group.

---

From: "Frank W. Miller" <[email-masked]>
Date: Sat, 28 Apr 2007 17:23:42 -0600

Acknowledged.  However, if we're talking about adding messaging
infrastructure to SIP, then the discussion is quite relevant here.  I
for one would vote for a simpler mechanism than multipart MIME XML blah
blah blah.  With regards to Keith's comments, I would love to sit down
and provide an alternative proposal but I just don't have the time to do
it.  With all due respect, I'll implement whatever the standards
committee comes up with, but I don't think its unreasonable for me or
anyone else to express concern about protocol that is obviously designed
by committee and obviously more complicated that it probably has to be.

FM

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 28 Apr 2007 16:42:27 -0700

Fair enough - I just want to try and keep the right parts of the  
discussion in the right place.

---

From: "Mark R. Lindsey" <[email-masked]>
Date: Sat, 28 Apr 2007 21:41:12 -0400

On Apr 28, 2007, at 4:25 PM, Juha Heinanen wrote:

> individual phones are.

In some major deployments, the data suggest otherwise: In two US-Baby- 
Bell's hosted VoIP system, 100% of their customers had a SIP B2BUA at  
every customer office. Ditto for another major vendor reselling  
hosted VoIP service to Baby Bells. The box handles NAT traversal  
among other functions.

So, in numerous cases, there is a SIP box between the SIP phone and  
the Service Provider. In many networks, including those with WiFi  
phones, the UAC can be compelled to register only through that B2BUA.

So there's real hope that inserting the location data at relatively  
few points can get this deployed on the calling-party side very rapidly.

> especially now when, for example, nokia

This is both a location-sensing & policy enforcement problem:

(a) If the location can be sensed by the enterprise operating a proxy/ 
B2BUA, then a proxy between the UA and the PSAP can insert the location.

(b) If the location can be sensed by the UA, then it can insert its  
own location.

(c) Else, if no location is provided to the service provider, an SP  
responsible for properly delivering emergency calls would refuse to  
let a device register.

Mark

---

From: [email-masked] (Juha Heinanen)
Date: Sun, 29 Apr 2007 05:51:40 +0300

> phones, the UAC can be compelled to register only through that B2BUA.

even if they register through their enterprise boxes, the UAs can still
be located wherever else than at that office.  people use vpns to get to
their offices from home/road/etc.  so i would say that it is actually
more harmful to give wrong location info (that of the office) than not to
give anything at all.

 > B2BUA, then a proxy between the UA and the PSAP can insert the

it is very hard to sense at the enterprise where my wlan hotspot
attached phone really is.

 > (b) If the location can be sensed by the UA, then it can insert its  

mobile networks do have location info, but they don't want to give it
out to the ua.  so if your sip service is not provided by your mobile
operator, you get nothing.   this actually proves that authorities value
much more business rights of mobile operators than safety of people.

 > responsible for properly delivering emergency calls would refuse to  

if you make such a law, sure there will be location info given, but in
many cases it will be bogus and thus more harmful than no info at all.

but this is not really a sip wg discussion other than it has been made
to spend its cycles on yet another useless standard.

-- juha

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sun, 29 Apr 2007 09:40:34 +0200

Hi Frank, 
Hi Jeroen, 
Hi Juha, 
Hi all 

what exactly is your complaint? Are you unhappy about
* XML encoding of location information
* location information carried in the body instead of the header
* number of location shapes (see http://www.ietf.org/internet-drafts/draft-ietf-geopriv-pdif-lo-profile-06.txt)
* the inability of GPS to work in certain environments
* Geopriv location and privacy architecture
* Ecrit emergency services architecture
?

Ciao
Hannes

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sun, 29 Apr 2007 15:36:56 +0200

Hi Hannes,

I was responding to Brian's message. He basically says: SIPit results show 
that the mechanisms needed to implement location conveyance are not widely 
implemented yet, we need to tell implementors to hurry it up

I question whether that approach works, and turn it around by asking: why 
are these mechanisms not implemented widely?

Personally I believe a significant part of the answer lies in the complexity 
of the proposed mechanisms, architecure, etc. So instead of trying to push 
the market to adopt the solution that is now on the table, perhaps we should 
look into what we can do to lower the barriers for adoption

Regards,
Jeroen

Hannes Tschofenig wrote:
> * number of location shapes (see
> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-pdif-lo-profile-06.txt)
> CC: \'IETF SIP List\' <[email-masked]>, [email-masked], Juha
> Heinanen <[email-masked]>, [email-masked], \'Robert
> Sparks\' <[email-masked]> Betreff: Re: [Sip] SIPit 20 survey
> summary
>
>>
>> for one would vote for a simpler mechanism than multipart MIME XML
>> blah blah blah.  With regards to Keith's comments, I would love to
>> sit down and provide an alternative proposal but I just don't have
>> the time to do it.  With all due respect, I'll implement whatever
>> the standards committee comes up with, but I don't think its
>> unreasonable for me or anyone else to express concern about protocol
>> that is obviously designed by committee and obviously more
>> complicated that it probably has to be.
>>
>> FM
>>
>>
>>> There has been an incredible amount of work on this topic across
>>> many standard organizations including the IETF. Before people start
>>> in on discussing this in - I strongly suggest they might want to
>>> read some of the requirements, uses cases, drafts, and mailing list
>>> discussions in ECRIT and GEOPRIV. Please keep in mind the charters
>>> of ECRIT/ GEOPRIV/SIP and take the discussion to the right working
>>> group.
>>>
>>>
>>>> i fully agree with this.  we should follow KISS principle here.
>>>> it is highly unlikely that sip ua vendors will even TRY implement
>>>> such a complex protocol.
>>>>
>>>> another reason why it will not get implemented is that sip uas
>>>> don't know where they are located.  gps does not work well indoors
>>>> and mobile

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 29 Apr 2007 09:58:31 -0400

For the record, I will note that I have made proposals for simple non- 
multipart location conveyance (using the data: URL), but various  
process-related arguments were made as to why we weren't allowed to  
look at that. (I'd prefer even simpler solutions, such as the one  
that XMPP uses, but that's beyond the political correctness limit in  
GEOPRIV.)

I tend to agree that exhortations to developers generally achieve  
little. On the other hand, I'm not sure that belly-aching about  
multipart is all that helpful. After all, most email clients support  
it and there are libraries in various languages to help with  
implementation. Generating multipart bodies is pretty trivial (as  
opposed to parsing them), and that's all embedded devices will  
generally have to do for location conveyance.

On Apr 29, 2007, at 9:36 AM, Jeroen van Bemmel wrote:

> Hi Hannes,
>
> I was responding to Brian's message. He basically says: SIPit  
> results show that the mechanisms needed to implement location  
> conveyance are not widely implemented yet, we need to tell  
> implementors to hurry it up
>
> I question whether that approach works, and turn it around by  
> asking: why are these mechanisms not implemented widely?
>
> Personally I believe a significant part of the answer lies in the  
> complexity of the proposed mechanisms, architecure, etc. So instead  
> of trying to push the market to adopt the solution that is now on  
> the table, perhaps we should look into what we can do to lower the  
> barriers for adoption
>
> Regards,
> Jeroen
>

---

From: [email-masked] (Juha Heinanen)
Date: Sun, 29 Apr 2007 17:15:18 +0300

Henning Schulzrinne writes:

 > (I'd prefer even simpler solutions, such as the one  

sip and xmpp should use identical format for location information.
there will be need to gw sip and xmpp and same format would make it
easy.  so my proposal is that sip ww just refers to
http://www.xmpp.org/extensions/xep-0080.html for location info.

-- juha

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sun, 29 Apr 2007 16:35:55 +0200

Hi Jeroen, 

I thought that Brian's message was adequate. For some reasons certain based SIP mechanisms have not widely been implemented. Some things take more time than others. 

I would also like to hear whether there are truely barriers for adoption or whether it just takes some time before we see certain features getting implemented. 

I would like to understand the complexity of the proposed mechanisms, if you see some. I am obviously in favor of simplifications.

Ciao
hannes

> complexity

---

From: Scott Lawrence <[email-masked]>
Date: Sun, 29 Apr 2007 10:47:23 -0400

> could add its location before sending the call to an SP.

On what basis would a proxy/B2BUA/ALG decide what location to add?  I
use the same proxy (in my office) from the same UA (on my laptop) from
many different locations.

> that can accept and use it.

I think that is easily refutable: compare of the number of PSAPs and
implementations intended for use in them against the number of telephony
providers, pbxs, user agents and implementations intended for such use.
There are very very few of the former, and they are very highly
motivated because they are providing the emergency services; it's the
latter that will take the greater time and effort.

-- 
Scott Lawrence  tel:+1-781-938-5306;ext=162 or sip:[email-masked]
  sipXecs project coordinator - SIPfoundry http://www.sipfoundry.org/sipXecs
  Chief Technology Officer    - Pingtel Corp. http://www.pingtel.com/

---

From: "Frank W. Miller" <[email-masked]>
Date: Sun, 29 Apr 2007 08:48:43 -0600

> that XMPP uses, but that's beyond the political correctness limit in  

Would it be possible to see these extensions?  Keith asked for
alternative proposals, it seems like looking at that might be a good
idea now.

> generally have to do for location conveyance.

As I said, I and others will implement whatever we're directed to.
Personally, I've got Expat in there now for PIDF and even parsing MP
MIME isn't really that hard.

My question is more focused on the essence of the Jeron's off-the-cuff
proposal.  Does the location information belong in the body or in the
main SIP headers?  I believe its the latter primarily for the argument
that was put forth, i.e. the information is so important it deserves
first-class treatment in the message headers.  The fact that its
simplified comes primarily from the fact that you need to be more
compact in your representation if your in the headers.

Dropping the return address list to [email-masked] only to minimize
messages in my inbox...

FM

---

From: [email-masked] (Juha Heinanen)
Date: Sun, 29 Apr 2007 17:52:56 +0300

Hannes Tschofenig writes:

 > I would like to understand the complexity of the proposed mechanisms,
 > if you see some. I am obviously in favor of simplifications.

number of lines in internet-draft:  2028
number of lines in xmpp spec:        410

just adopt the latter.

-- juha

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 29 Apr 2007 11:08:32 -0400

> alternative proposals, it seems like looking at that might be a good

The data URL proposal is simple and is (nominally) allowed within the  
SIP location conveyance document:

GeoLocation: data:application/xml+something,<base64 encoding of PIDF-LO>

(data URLs are defined in RFC 2397). This avoids the use of  
multipart, references and the difficulty of having proxies grope  
around in SIP multipart message bodies for routing-related information.

A more radical proposal is something along the lines of

Geolocation: 48.200927 16.369548 500 200

(longitude, latitude, altitude, 90% percentile accuracy of 200  
meters). Unfortunately, this doesn't generalize as easily to civic  
locations and to more complicated shapes.

> compact in your representation if your in the headers.

I don't think it's a matter merely of importance, more of function.  
Location is used for routing messages (as well as for the benefit of  
the end system), which is a header function in SIP. Bodies are meant  
for user agents.

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sun, 29 Apr 2007 17:12:48 +0200

I proposed something for conveying SAML assertions. Please find a bit of text in the issue tracker: 
http://www.tschofenig.priv.at:8080/saml-sip/issue9

There was also a maling list discussion about this subject but I have to search it. Was already some time ago.

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sun, 29 Apr 2007 17:19:00 +0200

Hi, 

I am not sure what drafts you counted but I noticed a couple of things that had an impact on the increase of pages in documents:

* Publication of documents for requirements, frameworks, document design considerations and design decisions
* More examples in the drafts 
* Security con
* Split documents to involve more people as draft authors 
  (=more documents, potentially smaller but each one of them with all the IETF document templates)

Hence, I am not so sure whether the number of papes actually indicate something about the amount of code you have to write. 

Ciao
Hannes

---

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Mon, 30 Apr 2007 00:45:23 +0200

(As WG chair)

Please do not misquote me. I have not asked for alternative proposals to
the matters you apparently are discussing.

On other threads, we are seeking WG consensus calls on specific
proposals; it is only on those specific proposals that I have asked for
alternative views. 

If you have a view on those specific proposals then please contribute to
those threads.

Regards

Keith 

> -----Original Message-----
> From: Frank W. Miller [mailto:[email-masked]] 
> Sent: Sunday, April 29, 2007 3:49 PM
> To: Henning Schulzrinne
> Cc: IETF SIP List; Robert Sparks
> Subject: Re: [Sip] SIPit 20 survey summary
> 
> > look at that. (I'd prefer even simpler solutions, such as 
> the one that 
> > XMPP uses, but that's beyond the political correctness limit in
> > GEOPRIV.)
> > 
> 
> Would it be possible to see these extensions?  Keith asked 
> for alternative proposals, it seems like looking at that 
> might be a good idea now.
> 
> 
> > little. On the other hand, I'm not sure that belly-aching IBq-0004wH-6x
	for [email-masked]; Sun, 29 Apr 2007 18:48:22 -0400
Content-class: urn:content-classes:message
Subject: RE: [Sip] SIPit 20 survey summary
Date: Mon, 30 Apr 2007 00:45:23 +0200
From: "Drage, Keith \(Keith\)" <[email-masked]>
To: "Frank W. Miller" <[email-masked]>
Cc: IETF SIP List <[email-masked]>

(As WG chair)

Please do not misquote me. I have not asked for alternative proposals to
the matters you apparently are discussing.

On other threads, we are seeking WG consensus calls on specific
proposals; it is only on those specific proposals that I have asked for
alternative views. 

If you have a view on those specific proposals then please contribute to
those threads.

Regards

Keith 

> -----Original Message-----
> From: Frank W. Miller [mailto:[email-masked]] 
> Sent: Sunday, April 29, 2007 3:49 PM
> To: Henning Schulzrinne
> Cc: IETF SIP List; Robert Sparks
> Subject: Re: [Sip] SIPit 20 survey summary
> 
> > look at that. (I'd prefer even simpler solutions, such as 
> the one that 
> > XMPP uses, but that's beyond the political correctness limit in
> > GEOPRIV.)
> > 
> 
> Would it be possible to see these extensions?  Keith asked 
> for alternative proposals, it seems like looking at that 
> might be a good idea now.
> 
> 
> Personally, I've got Expat in there now for PIDF and even 
> parsing MP MIME isn't really that hard.
> 
> My question is more focused on the essence of the Jeron's 
> off-the-cuff proposal.  Does the location information belong 
> in the body or in the main SIP headers?  I believe its the 
> latter primarily for the argument that was put forth, i.e. 
> the information is so important it deserves first-class 
> treatment in the message headers.  The fact that its 
> simplified comes primarily from the fact that you need to be 
> more compact in your representation if your in the headers.
> 
> Dropping the return address list to [email-masked] only to 
> minimize messages in my inbox...
> 
> 
> FM
> 
> 
> 
> 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip 

about 
> Personally, I've got Expat in there now for PIDF and even 
> parsing MP MIME isn't really that hard.
> 
> My question is more focused on the essence of the Jeron's 
> off-the-cuff proposal.  Does the location information belong 
> in the body or in the main SIP headers?  I believe its the 
> latter primarily for the argument that was put forth, i.e. 
> the information is so important it deserves first-class 
> treatment in the message headers.  The fact that its 
> simplified comes primarily from the fact that you need to be 
> more compact in your representation if your in the headers.
> 
> Dropping the return address list to [email-masked] only to 
> minimize messages in my inbox...
> 
> 
> FM
> 
> 
> 
> 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 29 Apr 2007 22:04:45 -0700

The extensibility model of SIP and SDP is very powerful in most ways.  
It is often done by adding a new thing and if both sides understand  
it, they use it, and if they don't understand it, they use the other  
data in the messages that they both do understand and "fall back" to  
the old behavior. We can do this for headers, URI, and other places  
in SIP. We can do if for SDP attributes. However, there is one place  
were SIP is very lacking in it's ability to be upgraded in the  
future. This is around body extensibility.

The typical way to deal with extensibility of bodies is using MIME  
multipart. This allows a SIP message to cary more than one body and  
the receiver to select and use whichever ones it understands - This  
is all defined for sip except for one problem. It was not mandatory  
to implement and as you can see from the stats below, lots of UAs  
don't implement it.

I believe that sooner or later we will have to do this - it's pretty  
trivial to implement support for receiving multipart even if SDP is  
the only thing your UA knows how to handle.  Now we could argue about  
if emergency calls were the thing that absolutely required us to do  
this but my point is sooner or later we are going to need to deal  
with this - it has come up many times in the past.  I suspect it will  
only get more difficult over time to make this change.

I think the WG should consider an update to 3261 (likely done through  
the process Keith has proposed) that makes this multipart/MIME  
mandatory to implement.

Cullen

On Apr 27, 2007, at 11:48 AM, Brian Rosen wrote:

> serious.

---

From: [email-masked]
Date: Mon, 30 Apr 2007 12:12:58 -0400

From: Cullen Jennings <[email-masked]>

I assume that the requirement is that if a message has a
multipart/alternative body, and the UA is capable of understanding one
part of the body, then it must be able to extract that part and use it
to process the message.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 30 Apr 2007 12:25:11 -0400

> part of the body, then it must be able to extract that part and use it

While there is a place for multipart/alternative, I think the key 
requirement is that if there is a multipart/mixed then the UA should 
look within it for one or more parts that it would know how to handle if 
they were the only part in the body.

While doing this it also needs to process the handling= parameter on the 
Content-Disposition header. It can ignore parts with handling=optional, 
but must punt if handling=required on some part and it doesn't know how 
to handle it.

Writing down precisely what handling multipart means in sip would make a 
nice little draft. I expect there would be at least a bit of controversy 
about it.

	Paul

---

From: "Frank W. Miller" <[email-masked]>
Date: Mon, 30 Apr 2007 10:28:14 -0600

Hmm.  Seems like the point of mine and others emails was simplification.
Somehow its come round now to a discussion of forcing implementors to do
something more complicated...     ;)

FM

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 30 Apr 2007 13:19:25 -0500

I agree that we should make support for Multipart/MIME mandatory.

I.e., that you must be able to decapsulate the parts and parse
the ones you do support.

> From: Cullen Jennings [mailto:[email-masked]] 
> Sent: Sunday, April 29, 2007 22:05
> To: IETF SIP List
> Subject: [Sip] Support for Multipart/MIME
> 
> 
> It is often done by adding a new thing and if both sides 
> understand it, they use it, and if they don't understand it, 
> they use the other data in the messages that they both do 
> understand and "fall back" to the old behavior. We can do 
> this for headers, URI, and other places in SIP. We can do if 
> for SDP attributes. However, there is one place were SIP is 
> very lacking in it's ability to be upgraded in the future. 
> This is around body extensibility.
> 
> The typical way to deal with extensibility of bodies is using 
> MIME multipart. This allows a SIP message to cary more than 
> one body and the receiver to select and use whichever ones it 
> understands - This is all defined for sip except for one 
> problem. It was not mandatory to implement and as you can see 
> from the stats below, lots of UAs don't implement it.
> 
> I believe that sooner or later we will have to do this - it's 
> pretty trivial to implement support for receiving multipart 
> even if SDP is the only thing your UA knows how to handle.  
> Now we could argue about if emergency calls were the thing 
> that absolutely required us to do this but my point is sooner 
> or later we are going to need to deal with this - it has come 
> up many times in the past.  I suspect it will only get more 
> difficult over time to make this change.
> 
> I think the WG should consider an update to 3261 (likely done 
> through the process Keith has proposed) that makes this 
> multipart/MIME mandatory to implement.
> 
> Cullen
> 
> 
> >> me
> > order to support location for emergency calls (citizen to 
> authority, 
> > like
> > 1-1-2 or
> > I believe it is likely that there will eventually be regulatory 
> > requirements to support emergency calls in some jurisdictions.  
> > Upgrades to several components of today's infrastructure will be 
> > needed before this all works, but stack vendors and UA developers 
> > should put multipart (and
> > location-conveyance) on their development plans for next 
> year at the 
> > latest.
> >
> > Brian
> 
>

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 30 Apr 2007 13:32:21 -0500

>I.e., that you must be able to decapsulate the parts and parse

I agree with addressing Multipart now

A short requirements ID that becomes (no need for separate RFCs) a 
solutions doc will flesh all these individual details out (wrt which 
multipart needs to be supported (all?), and what to do with the 
Content-Disposition header values that may or may not also need to be 
accompanying such an extension in the message.