Subject: [Sip] I-D Action:draft-ietf-sip-info-events-00.txt

From: [email-masked]
Date: Mon, 20 Oct 2008 16:15:02 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.

	Title           : Session Initiation Protocol (SIP) INFO Method and Package Framework
	Author(s)       : E. Burger, et al.
	Filename        : draft-ietf-sip-info-events-00.txt
	Pages           : 29
	Date            : 2008-10-20

This document defines the new INFO method and a mechanism for
defining, negotiating and exchanging Info Packages that use the INFO
method.  Applications which need to exchange session-related
information within a SIP INVITE-created dialog use these INFO
requests.  This draft addresses issues and open items from RFC 2976,
and replaces it.Conventions Used in this Document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-info-events-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Sip mailing list  https://www.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: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Tue, 21 Oct 2008 01:39:10 +0200

(As WG chair)

This is the draft that is supposed to solve all the INFO problems we
ever had and ever will have in future.

Note that the current version of the draft obsoletes (replaces) RFC
2976, i.e. the existing INFO method documentation.

There are a couple of open issues in the document where I believe the
editor's will be initiating discussion shortly - so you may want to wait
for those on the TBD.

Otherwise, let the discussion commence. You may want to try and raise
different issues in different emails, in order to allow these to be kept
track of.

Regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: Tuesday, October 21, 2008 12:15 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Sip] I-D Action:draft-ietf-sip-info-events-00.txt
> 
> defining, negotiating and exchanging Info Packages that use 
> the INFO method.  Applications which need to exchange 
> session-related information within a SIP INVITE-created 
> dialog use these INFO requests.  This draft addresses issues 
> and open items from RFC 2976, and replaces it.Conventions 
> Used in this Document
> 
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 
> NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 
> "OPTIONAL" in this document are to be interpreted as 
> described in RFC 2119 [RFC2119].
> 
> Below is the data which will enable a MIME compliant mail 
> reader implementation to automatically retrieve the ASCII 
> version of the Internet-Draft.
>

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 21 Oct 2008 15:41:30 +0100

Some comments:

"Info Package negotiation is similar, but not the same, as negotiating
   SDP [RFC3264].  It is similar, in that the UAC may offer a set of
   Send-Info and Recv-Info packages in the initial INVITE, the UAS
   offers its set of Send-Info and Recv-Info pacakges in provisional 1xx
   and final 2xx responses, and the UAC may offer a final set of Send-
   Info and Recv-Info packages in the ACK."
This sounds like a 3-way exchange, which is not the same as for SDP. I
believe a 2-way exchange, as for SDP, is intended. This interpretation
seems to be in line with 4.2 and 4.3, but 4.1 seems to suggest a 3-way
handshake. Clarification is needed in several places.

"The
   general rule is before a UA may begin sending INFO methods with a
   given Info Package, the UAC must have first indicated it wants to
   send the Info Package by listing it in a Send-Info header in the most
   recent dialog negotiation and the UAS must have positively indicated
   it is willing to receive the Info Package by listing it in a Recv-
   Info header in the most recent dialog negotiation."
Not necessarily. This only applies before a UAC can begin sending.
Before a UAS can begin sending, the opposite must have happened, i.e.,
the UAS must have indicated willingness to send and the UAC must have
indicated willingness to received.

"Once the UAC and UAS establish an early dialog through a 1xx
   provisional response with To-tags, and the UAC has received a Recv-
   Info header field values from the UAS in the response, the UAC MAY
   send any Info Packages supported by the UAS in an INFO message.  The
   2xx final response updates the state of the supported Info Packages,
   such that the 2xx contains the full and final list of Send-Info and
   Recv-Info Info Packages."
This text does not seem to allow for receipt of a 2xx response without
having received a 1xx provisional response.

"Any proposal to have INFO change
   the state of a SIP call is an architectural error and one MUST NOT
   allow it."
Who or what is "one"? For any normative statement, we have to be clear
to whom or what it applies.

John

> Behalf Of DRAGE, Keith (Keith)
> Sent: 21 October 2008 00:39
> To: [email-masked]
> Subject: Re: [Sip] I-D Action:draft-ietf-sip-info-events-00.txt
> 
> (As WG chair)
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Oct 2008 10:52:37 -0400

While I see rules in 5.1 and 6 that permit use of legacy packages at the 
INFO UAS, I find no rules that permit sending a legacy INFO. I guess it 
must be possible to use legacy INFO even when both sides support this 
new info package mechanism. And I guess the evidence that a UA *doesn't* 
support this new mechanism (by the absence of the headers in 
request/response) is just equivalent to one that explicitly negotiates 
support of no packages.

Regarding registration if INFO packages - I thought we also wanted to 
introduce a registry for legacy usages of INFO, to encourage them to 
come out into the daylight. I guess maybe that would be a separate 
registry, since the key for it will have to be Content-Type. So it 
*could* be established from a different document. But I think this is 
the likely place to do it, since its the place where all the eyeballs 
will be. I think the rule for registering those needs to be that one can 
only be registered if the Content-Type has not already been registered, 
and it was in *use* with INFO prior to this document becoming an RFC. 
(The registration itself could be done later. I guess it would be the 
honor system.) Any usages being deployed after this becomes an RFC would 
be required to use the new mechanism.

	Thanks,
	Paul

---

From: Salvatore Loreto <[email-masked]>
Date: Sat, 25 Oct 2008 19:21:34 +0300

the following paragraph of Section 5.2 puzzles me:

   If a server receives an INFO request with a body it understands, but
   it has no Info-Package header, the UAS MAY render the body.  Note the
   semantics of "rendering" is up to the Info Package definition.  The
   UAS MUST respond to the INFO request with a 200 OK.  This enables
   legacy use of INFO.

Now it states that is to enable legacy use of INFO, but at same time 
refer to the Info Package definition
that is something only for the new usage.

IMO with this text it would be possible send also an INFO request the 
other end is not willing to receive,
it is enough not include the Info-Package header. Is this can be seen as 
a possible security problem?

Thanks
Sal

Paul Kyzivat wrote:
> While I see rules in 5.1 and 6 that permit use of legacy packages at 
> the INFO UAS, I find no rules that permit sending a legacy INFO. I 
> guess it must be possible to use legacy INFO even when both sides 
> support this new info package mechanism. And I guess the evidence that 
> a UA *doesn't* support this new mechanism (by the absence of the 
> headers in request/response) is just equivalent to one that explicitly 
> negotiates support of no packages.
>
> will be. I think the rule for registering those needs to be that one 
> can only be registered if the Content-Type has not already been 
> registered, and it was in *use* with INFO prior to this document 
> becoming an RFC. (The registration itself could be done later. I guess 
> it would be the honor system.) Any usages being deployed after this 
> becomes an RFC would be required to use the new mechanism.
>
> Thanks,
> Paul
>
>
>
>
>
>
>
>
>
>
>
>
>

---

From: Eric Burger <[email-masked]>
Date: Thu, 30 Oct 2008 12:13:57 -0400

We discussed creating a registry, and we discussed whether it would be  
in this document.

On the one hand, the discussion was not conclusive.  On the other,  
here are my reasons for not including it in the Info Packages document:

1. We go at lengths to say how to do Info Packages.  The last thing we  
need to do is say, "by the way, it's not so bad if you don't."

2. People not involved today will look at such a registry and, no  
matter how much doom and gloom wording we use, will think it's OK to  
not use Info Packages.

3. People will be confused, thinking Content-Type is sufficient to  
identify an Info Package.  It is not.

4. How would we possibly police the registry? If someone comes to IANA  
to register a new MIME type do the klaxons ring?  That would not be a  
good thing.

So, time for another poll:
[ ] Yes - we really, really need an IANA registry of "legacy" INFO  
usages, and we need it done in this draft
     (NOTE: creating the IANA registry requires the seed values, which  
means this draft will enumerate the
      known legacy usages)

[ ] No, do not create an IANA registry, but please enumerate known  
legacy usages in this draft

[ ] No - please do not create an IANA registry

[ ] Punt - I may or may not want an IANA registry, but if we do create  
one, do it in another draft

[ ] Other: ________________________________

On Oct 21, 2008, at 10:52 AM, Paul Kyzivat wrote:

> Regarding registration if INFO packages - I thought we also wanted  
> to introduce a registry for legacy usages of INFO, to encourage them  
> to come out into the daylight. I guess maybe that would be a  
> separate registry, since the key for it will have to be Content- 
> Type. So it *could* be established from a different document. But I  
> think this is the likely place to do it, since its the place where  
> all the eyeballs will be. I think the rule for registering those  
> needs to be that one can only be registered if the Content-Type has  
> not already been registered, and it was in *use* with INFO prior to  
> this document becoming an RFC. (The registration itself could be  
> done later. I guess it would be the honor system.) Any usages being  
> deployed after this becomes an RFC would be required to use the new  
> mechanism.

---

From: Eric Burger <[email-masked]>
Date: Thu, 30 Oct 2008 12:43:46 -0400

I see this as no worse than what we have today, and there is little we  
can do about it.  A bad UAC implementation is a bad UAC.

Unfortunately, this is one of those excuses for an SBC...

On Oct 25, 2008, at 12:21 PM, Salvatore Loreto wrote:

> IMO with this text it would be possible send also an INFO request  
> the other end is not willing to receive,
> it is enough not include the Info-Package header. Is this can be  
> seen as a possible security problem?
>
> Thanks
> Sal
>
>
> Paul Kyzivat wrote:
>> While I see rules in 5.1 and 6 that permit use of legacy packages  
>> at the INFO UAS, I find no rules that permit sending a legacy INFO.  
>> I guess it must be possible to use legacy INFO even when both sides  
>> support this new info package mechanism. And I guess the evidence  
>> that a UA *doesn't* support this new mechanism (by the absence of  
>> the headers in request/response) is just equivalent to one that  
>> explicitly negotiates support of no packages.

---

From: Dean Willis <[email-masked]>
Date: Thu, 30 Oct 2008 14:13:29 -0500

On Oct 30, 2008, at 11:13 AM, Eric Burger wrote:

--
Dean

---

From: "Beith, Gordon" <[email-masked]>
Date: Thu, 30 Oct 2008 15:36:44 -0400

I also support 
 [X] No, do not create an IANA registry, but please enumerate known
legacy usages in this draft

/Gordon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Dean Willis
Sent: Thursday, October 30, 2008 12:13 PM
To: Eric Burger
Cc: SIP IETF; Paul Kyzivat
Subject: Re: [Sip] Legacy Info Package Registration

On Oct 30, 2008, at 11:13 AM, Eric Burger wrote:

--
Dean

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 30 Oct 2008 15:05:25 -0500

[X] Punt - I may or may not want an IANA registry, but if we do create
one, do it in another draft

I think we should punt for now. However, IF we decide that for SIP, as a
whole, we do try to bring more real implemenation stuff into the fold,
then I think we should have a registry, that should be included in a
separate document. I'm afraid we may get very delayed if we try to do
that now, as there may be a tendency to analyze legacy usages in terms
of how reasonable people think they are - i.e., there may be some for
which there is a clear standard's solution and then we'll debate whether
we include them all whether folks would ever deem them useful or not.   

Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Eric Burger
Sent: Thursday, October 30, 2008 11:14 AM
To: Paul Kyzivat
Cc: SIP IETF
Subject: [Sip] Legacy Info Package Registration

On the one hand, the discussion was not conclusive.  On the other, here
are my reasons for not including it in the Info Packages document:

2. People not involved today will look at such a registry and, no matter
how much doom and gloom wording we use, will think it's OK to not use
Info Packages.

On Oct 21, 2008, at 10:52 AM, Paul Kyzivat wrote:

> registry, since the key for it will have to be Content- Type. So it

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 30 Oct 2008 16:32:53 -0400

In some sense "enumerate known legacy usages" is what I hoped the 
registry would do. If we just try to do it in this document, without 
provision for update, then which ones will we get, and which will we miss?

I am opposed to a registry of legacy issues if it isn't restricted to 
*legacy* uses. I'd like to restrict it to usages that were in production 
use prior to the info usage draft - say before the end of 2008. But I 
don't know how to put teeth into that, if somebody comes along in 2010 
and says "I have this info usage that I have been using since 2004 but I 
didn't know about this registry till now." I think it must be honor 
system, and I don't know how well that will work.

Regarding keeping the registry separate from the info package document: 
when the document describes legacy usage, IMO it would be helpful to say 
that to comply with the new document, the legacy usages you use must be 
registered in the registry. That would provide some incentive to get 
that registry populated. In terms of encouraging migration to the info 
packages, we would have to depend on the honor system for legacy usage.

Eric Burger wrote:

> [1] Yes - we really, really need an IANA registry of "legacy" INFO 
> [2] Punt - I may or may not want an IANA registry, but if we do create 

I can go with either of the above.

	Thanks,
	Paul

---

From: Ben Campbell <[email-masked]>
Date: Thu, 30 Oct 2008 15:33:15 -0500

> legacy usages in this draft

+1

(With a second choice of punt)

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Fri, 31 Oct 2008 00:09:57 +0100

(As individual)

At the moment I think this draft should concentrate on the packages, and
interoperability with the legacy issues.

I don't think I want to identify (except by way of example for the
above) any of the legacy usages.

I do not have an objection to creating another draft that creates a
registry of legacy usages, and if that wants to list known ones then
fine. I have no objection if we do that now or later, but the main draft
would not be dependent on it.

I would note that if we do create a registry, then whether we need to
seed it or not depends on the registration criteria - if it is first
come first served, then anyone can register their own legacy usages
without waiting for an RFC to do it for them. 

At the moment I am also unsure what criteria we would use for identifing
a legacy usage, apart from some rather vague textual description. It
after all does not have a package name. 

So I'll accept either of these:

> [ ] Punt - I may or may not want an IANA registry, but if we 
> do create one, do it in another draft

regards

Keith

> Behalf Of Eric Burger
> Sent: Thursday, October 30, 2008 4:14 PM
> To: Paul Kyzivat
> Cc: SIP IETF
> We discussed creating a registry, and we discussed whether it 
> would be in this document.
> 
> On the one hand, the discussion was not conclusive.  On the 
> other, here are my reasons for not including it in the Info 
> Packages document:
> 
> 1. We go at lengths to say how to do Info Packages.  The last 
> thing we need to do is say, "by the way, it's not so bad if 
> you don't."
> 
> 2. People not involved today will look at such a registry 
> and, no matter how much doom and gloom wording we use, will 
> think it's OK to not use Info Packages.
> 
> 3. People will be confused, thinking Content-Type is 
> sufficient to identify an Info Package.  It is not.
> 
> 4. How would we possibly police the registry? If someone 
> comes to IANA to register a new MIME type do the klaxons 
> ring?  That would not be a good thing.
> 
> [ ] Yes - we really, really need an IANA registry of "legacy" 
> INFO usages, and we need it done in this draft
>      (NOTE: creating the IANA registry requires the seed 
> values, which means this draft will enumerate the
>       known legacy usages)
> 
> [ ] No, do not create an IANA registry, but please enumerate 
> known legacy usages in this draft
> 
> [ ] Punt - I may or may not want an IANA registry, but if we 
> do create one, do it in another draft
>

---

From: Bob Penfield <[email-masked]>
Date: Thu, 30 Oct 2008 19:55:38 -0400

I'm think I agree with Keith.

How about:

 [X] No, do not create an IANA registry, but please enumerate
 known legacy usages in separate draft

cheers,
(-:bob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of DRAGE, Keith (Keith)
Sent: Thursday, October 30, 2008 7:10 PM
To: Eric Burger; Paul Kyzivat
Cc: SIP IETF
Subject: Re: [Sip] Legacy Info Package Registration

(As individual)

regards

Keith

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 30 Oct 2008 20:43:20 -0400

> after all does not have a package name. 

With legacy usage, the only distinguishing characteristic that I am 
aware has ever been used is Content-Type. So I think the registry has to 
be based on Content-Type, probably on a FCFS basis. (Though perhaps 
there might be need of an appeals process if there are conflicting 
usages. But I doubt we will find that.)

	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 31 Oct 2008 14:10:42 +0100

Hi,

I guess one option is to e.g. have an annex, where we for legacy usages
list Content-Type and a reference (if available) to where the usage is
described.

If there are different legacy usages with the same Content-Type, I don't
think we should deal with that. That would just show the need for the
info packages.

Also, I don't think we would need to collect each and every legacy usage
out there (I am not sure we would manage to do that even with a
registry).

Regards,

Christer

> Behalf Of Paul Kyzivat
> Sent: 31. lokakuuta 2008 2:43
> To: DRAGE, Keith (Keith)
> Cc: SIP IETF
> > At the moment I am also unsure what criteria we would use for 
> > identifing a legacy usage, apart from some rather vague textual 
> > description. It after all does not have a package name.
> 
> With legacy usage, the only distinguishing characteristic 
> that I am aware has ever been used is Content-Type. So I 
> think the registry has to be based on Content-Type, probably 
> on a FCFS basis. (Though perhaps there might be need of an 
> appeals process if there are conflicting usages. But I doubt 
> we will find that.)
> 
> 	Paul
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 31 Oct 2008 09:39:06 -0400

Now that you mention it, allowing multiple definitions for the same C-T 
probably does make sense, though we hope there aren't any such cases.
This is only for legacy, so we won't be making the problem worse that way.

The advantage of a registry is that there isn't a deadline for when 
things are added to it. If another legacy usage is discovered in a few 
years, it can be added to a registry. But if we just put the list in a 
document, then it only contains those we find before the doc is finalized.

	Thanks,
	Paul

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 31 Oct 2008 09:07:30 -0500

Per your last point, this is why I "voted" as I did. I think it's
important if we do document legacy to have a registry, so it's much
easier to find. Unfortunately, when folks read drafts, they usually read
only the sections that are related to why they picked up the doc in the
first place and don't always comprehensively review the doc. 

Based on some offline discussions, I think the legacy issue is not as
bad as I had thought it would be. But, still a registry is most useful.
And, again, we don't want this doc held up while we go searching for
those. And, we don't want to have to update this doc later to add more
(or worse yet, have them end up in a separate doc). The addition of the
legacy usages should be quick and easy and maybe we can just designate a
prime as first point of contact to offload chairs.

Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Paul Kyzivat
Sent: Friday, October 31, 2008 8:39 AM
To: Christer Holmberg
Cc: SIP IETF; DRAGE,Keith (Keith)
Subject: Re: [Sip] Legacy Info Package Registration

Now that you mention it, allowing multiple definitions for the same C-T
probably does make sense, though we hope there aren't any such cases.
This is only for legacy, so we won't be making the problem worse that
way.

The advantage of a registry is that there isn't a deadline for when
things are added to it. If another legacy usage is discovered in a few
years, it can be added to a registry. But if we just put the list in a
document, then it only contains those we find before the doc is
finalized.

	Thanks,
	Paul

Christer Holmberg wrote:
> Hi,
> 
> I guess one option is to e.g. have an annex, where we for legacy 
> usages list Content-Type and a reference (if available) to where the 
> usage is described.
> 
> If there are different legacy usages with the same Content-Type, I 
> don't think we should deal with that. That would just show the need 
> for the info packages.
> 
> Also, I don't think we would need to collect each and every legacy 
> usage out there (I am not sure we would manage to do that even with a 
> registry).
> 
> Regards,
> 
> Christer
> 
> 
> 
> 

>> Paul Kyzivat
>> aware has ever been used is Content-Type. So I think the registry has

>> to be based on Content-Type, probably on a FCFS basis. (Though 
>> perhaps there might be need of an appeals process if there are 
>> conflicting usages. But I doubt we will find that.)
>>
>> 	Paul
>> [email-masked] for questions on current sip Use 
>> [email-masked] for new developments on the application of sip
>>
> 
_______________________________________________
Sip mailing list  https://www.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
_______________________________________________
Sip mailing list  https://www.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