Subject: [Sip] draft-ietf-sip-info-events-00: multiple packages per INFO

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

Re the question about multiple packages per INFO:

    There MUST be exactly one Info Package type listed per Info-Package
    header.  Multiple Info-Packages per INFO message are disallowed.

    [EDITOR NOTE: Really?  Why not multiple Info-Packages, in a
    multipart/mime?  Well, I thought of one: it is hard to disambiguate.
    For example, take an INFO message with an Info-Package: key_image,
    caller_picture.  I then have a multipart/mime with, you guessed it,
    an image/jpeg and an image/jpeg.  I would offer we do allow this and
    require the MIME parse order of the body match the order of the Info-
    Package enumerations; if you have too many packages or body parts or
    they do not align, you barf.  However, I timed out on this and thus
    we will have to wait for the next version for me to flesh this out.
    If we do do this, then we'll reference RFC 3261 as updated by
    draft-ietf-sip-body-handling to require multipart MIME handling.]

How about defining an initial package type of "multipart". It allows 
only content-type multipart/mixed. Then each contained type must have 
its own Info-Package header. If you want to allow multiple packages per 
INFO then you need to negotiate support for "multipart". Or maybe we 
require support of multipart if you support any other package type.

	Thanks,
	Paul
_______________________________________________
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: "Christer Holmberg" <[email-masked]>
Date: Wed, 22 Oct 2008 09:54:09 +0200

Hi,

Doesn't the body handling draft say that one MUST be able to parse
multipart message bodies?

So, I don't think we should forbid the usage of multiple packages. There
MAY be use-cases where it is useful, so...

I also think that the negotiation of multipart support is more generic,
so such mechanism should not be bound to INFO packages.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Paul Kyzivat
Sent: 21. lokakuuta 2008 17:45
To: SIP IETF; Eric Burger
Subject: [Sip] draft-ietf-sip-info-events-00: multiple packages per INFO

    require the MIME parse order of the body match the order of the
Info-

	Thanks,
	Paul
_______________________________________________
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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Oct 2008 09:36:05 -0400

> so such mechanism should not be bound to INFO packages.

My thinking was:

If multipart is used to convey multiple info packages, then each part 
that contains an info package should contain an Info-Package header 
stating which package it is. That was an alternative to Eric's proposal 
that all the packages be listed at the outer level.

Then the question remained: in this case should there be an Info-Package 
header at the outer level, and if so, what should it contain?

Answering that question is what led to my proposing the "multipart" package.

I guess an alternative would be for the Info-Package header at the outer 
level to list all the packages contained, in no particular order, and 
then for the individual parts to contain an Info-Package describing that 
part.

I do think it is necessary for there to be an Info-Package header at the 
outer level, to distinguish this from a legacy use of Info.

	Thanks,
	Paul

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Wed, 22 Oct 2008 15:41:05 +0200

There is is disconnect in the argument here.

Just because SIP requires (or now nearly requires) multipart body
handling doesn't mean that we have to define the meaning of multiple
bodies of the same type for every usage.

And surely there are wider things bound up here. For example is it not
still up to the application using INFO to ensure in order delivery if
that is what it requires. One way of doing this is to constrain the
transport mechanism to not send another INFO until the previous has been
acknowledged. If so, then different applications may have different
requirements in this respect that interact.

Why does putting two different packages in the same INFO work better
than two different INFO messages each with their own package usage? Is
there a desirable relationship that can be implemented between the two
that we would otherwise lose?

Regards

Keith

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Christer Holmberg
> Sent: Wednesday, October 22, 2008 8:54 AM
> To: Paul Kyzivat; SIP IETF; Eric Burger
> Subject: Re: [Sip] draft-ietf-sip-info-events-00: multiple 
> packages per INFO
> 
> 
> Hi,
> 
> Doesn't the body handling draft say that one MUST be able to 
> parse multipart message bodies?
> 
> So, I don't think we should forbid the usage of multiple 
> packages. There MAY be use-cases where it is useful, so...
> 
> I also think that the negotiation of multipart support is 
> more generic, so such mechanism should not be bound to INFO packages.
> 
> Regards,
> 
> Christer
> 
> 
> 
>  
> 
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Paul Kyzivat
> How about defining an initial package type of "multipart". It 
> allows only content-type multipart/mixed. Then each contained 
> type must have its own Info-Package header. If you want to 
> allow multiple packages per INFO then you need to negotiate 
> support for "multipart". Or maybe we require support of 
> multipart if you support any other package type.
> 
> 	Thanks,
> 	Paul
> [email-masked] for questions on current sip 
> Use [email-masked] for new developments on the application 
> of sip _______________________________________________
> [email-masked] for questions on current sip

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 22 Oct 2008 19:20:10 +0200

Hi,

>bodies of the same type for every usage.

Of course not. But, unless there are good reasons I don't think we should forbid it - in case there will be future use-cases where it could be useful.

>requirements in this respect that interact.

Correct. So, this would only be used if it fulfills all those requirements.

>that we would otherwise lose?

Well, that brings up a good question: assuming it is allowed to send multiple info packages in a single INFO, does that automatically mean that there must be a desirable relationship? I don't think so.
 
If there is a relationship that should be described in the application logic itself.
 
Regards,
 
Christer

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Wed, 22 Oct 2008 19:33:39 +0200

Christer said in reply to me:

> Well, that brings up a good question: assuming it is allowed 
> to send multiple info packages in a single INFO, does that 
> automatically mean that there must be a desirable 
> relationship? I don't think so.
>  

That was not an answer to my question.

What I was trying to get to was whether providing two INFOs each containing one package provided the same solution as one INFO containing two packages  (and assuming anyone has a use case for two packages on the same dialog - something I don't believe I have yet seen presented to the list - did I miss it somewhere). 

If the answer is yes, then it becomes a matter of deciding whether we want one solution or two to be documented, and if one, then which one. 

If the answer is no, then we need to understand the why and wherefore of those differences before deciding what documentation to provide.

Regards

Keith 

> From: Christer Holmberg [mailto:[email-masked]] 
> Sent: Wednesday, October 22, 2008 6:20 PM
> To: DRAGE, Keith (Keith); Paul Kyzivat; SIP IETF; Eric Burger
> Subject: RE: [Sip] draft-ietf-sip-info-events-00: multiple 
> packages per INFO
> 
> Hi,
> 
> Of course not. But, unless there are good reasons I don't 
> think we should forbid it - in case there will be future 
> use-cases where it could be useful.
> 
> >transport mechanism to not send another INFO until the previous has 
> >been acknowledged. If so, then different applications may have 
> >different requirements in this respect that interact.
> 
> Well, that brings up a good question: assuming it is allowed 
> to send multiple info packages in a single INFO, does that 
> automatically mean that there must be a desirable 
> relationship? I don't think so.
>  
> > Subject: Re: [Sip] draft-ietf-sip-info-events-00: multiple packages 
> > per INFO
> >
> >
> > Hi,
> >
> > So, I don't think we should forbid the usage of multiple packages. 
> > There MAY be use-cases where it is useful, so...
> >
> > I also think that the negotiation of multipart support is more 
> > generic, so such mechanism should not be bound to INFO packages.
> >
> > Regards,
> >
> > Christer
> >
> >
> >
> > 
> >
> Behalf Of 
> >     an image/jpeg and an image/jpeg.  I would offer we do 
> allow this 
> > and
> >     Package enumerations; if you have too many packages or 
> body parts 
> > or
> > its own Info-Package header. If you want to allow multiple packages 
> > per INFO then you need to negotiate support for 
> "multipart". Or maybe 
> > we require support of multipart if you support any other 
> package type.
> >
> >       Thanks,
> >       Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Oct 2008 14:19:29 -0400

Keith,

IMO sending two info packages in separate INFO messages should produce 
the same behavior as sending them in one. Except perhaps for order of 
processing. If we choose to define sending two in one INFO, then I think 
we need to specify how the ordering is supposed to work. (E.g. that they 
should be processed in the same order as they appear in the multipart, 
and that in such case the behavior MUST be the same as if they were sent 
in separate messages in that order.)

The one advantage that comes to mind is that if you can't do this, then 
you really need to wait for the round trip of one info before sending 
another, which could be inconvenient and delay inducing if you get the 
data for more than one at the same time.

But we could certainly just decide not to define that now, and leave it 
till later to decide if sending multiple packages is useful.

An problem with defining this is that it introduces another sort of 
error to handle if one package can be dealt with but another cannot.

I guess I'd be inclined not to define it for now.

	Thanks,
	Paul

DRAGE, Keith (Keith) wrote:
>>> Christer Holmberg

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Wed, 22 Oct 2008 23:45:40 +0200

Thanks for the direct answer to my question.

> IMO sending two info packages in separate INFO messages 
> should produce the same behavior as sending them in one. 
> Except perhaps for order of processing. If we choose to 
> define sending two in one INFO, then I think we need to 
> specify how the ordering is supposed to work. (E.g. that they 
> should be processed in the same order as they appear in the 
> multipart, and that in such case the behavior MUST be the 
> same as if they were sent in separate messages in that order.)

Surely here you are implying that the two packages have a dependency. That's two steps of use cases, i.e. that there is a requirement for more than one use case in the first place, and then the use case for the two packages being interdependent in terms of data content.

If there is not such dependency, but the two packages both require in order delivery for their own data, then surely each package not sending the next INFO until it has received the response for the previous one within its package is a sufficient mechanism at the level of INFO and the body packaging.

Regards

Keith

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Wednesday, October 22, 2008 7:19 PM
> To: DRAGE, Keith (Keith)
> Cc: Christer Holmberg; SIP IETF; Eric Burger
> IMO sending two info packages in separate INFO messages 
> should produce the same behavior as sending them in one. 
> Except perhaps for order of processing. If we choose to 
> define sending two in one INFO, then I think we need to 
> specify how the ordering is supposed to work. (E.g. that they 
> should be processed in the same order as they appear in the 
> multipart, and that in such case the behavior MUST be the 
> same as if they were sent in separate messages in that order.)
> 
> The one advantage that comes to mind is that if you can't do 
> this, then you really need to wait for the round trip of one 
> info before sending another, which could be inconvenient and 
> delay inducing if you get the data for more than one at the same time.
> 
> But we could certainly just decide not to define that now, 
> and leave it till later to decide if sending multiple 
> packages is useful.
> 
> An problem with defining this is that it introduces another 
> sort of error to handle if one package can be dealt with but 
> another cannot.
> 
> >> Well, that brings up a good question: assuming it is 
> allowed to send 
> >> multiple info packages in a single INFO, does that 
> automatically mean 
> >> that there must be a desirable relationship? I don't think so.
> >>  
> > What I was trying to get to was whether providing two INFOs 
> each containing one package provided the same solution as one 
> INFO containing two packages  (and assuming anyone has a use 
> case for two packages on the same dialog - something I don't 
> believe I have yet seen presented to the list - did I miss it 
> somewhere). 
> > 
> > If the answer is yes, then it becomes a matter of deciding 
> whether we want one solution or two to be documented, and if 
> one, then which one. 
> > 
> > If the answer is no, then we need to understand the why and 
> wherefore of those differences before deciding what 
> documentation to provide.
> > 
> > Regards
> > 
> > Keith
> > 
> packages 
> >> Of course not. But, unless there are good reasons I don't think we 
> >> should forbid it - in case there will be future use-cases where it 
> >> could be useful.
> >>
> >> Well, that brings up a good question: assuming it is 
> allowed to send 
> >> multiple info packages in a single INFO, does that 
> automatically mean 
> >> that there must be a desirable relationship? I don't think so.
> >>  
> packages. 
> >>> Subject: [Sip] draft-ietf-sip-info-events-00: multiple 
> packages per 
> >>> INFO
> >>>
> >>>     caller_picture.  I then have a multipart/mime with, 
> you guessed 
> >>> it,
> >>>     they do not align, you barf.  However, I timed out on 
> this and 
> >>> thus
> >>>     we will have to wait for the next version for me to 
> flesh this 
> >>> out.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Oct 2008 18:04:35 -0400

Keith,

The reason for awaiting a reply before sending another INFO is because 
if you don't do that, and the messages get reordered, then the last one 
to arrive will fail due to CSeq ordering. That's not a good thing, 
though I guess it would be simple enough to retry it in that case.

I would assume that in most cases the actual order of processing would 
not matter for different package types.

	Thanks,
	Paul

---

From: Dean Willis <[email-masked]>
Date: Wed, 22 Oct 2008 19:46:47 -0500

> that we would otherwise lose?

We have one package per NOTIFY. Let's stick with one package per INFO,  
unless we want to go back to using mime-types as the only  
distinguisher of packages.

--
Dean

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 23 Oct 2008 03:03:46 +0200

In order delivery and reliable delivery are different things but in many cases they are linked. I suspect that if an application is prepared to accept out of order delivery it is also prepared to accept unreliable delivery. 

This may be because the application provides its own sequencing and retransmission mechanisms, or because it just plain does not matter to the application.

I believe that the original INFO RFC allowed outstanding INFO transactions to exist before initiating another. This carried the implications you mention. It was up to the application to decide whether that was acceptable, or whether it relied on waiting for the response to a previous INFO transaction before commencing another as its protection mechanism.

I believe where we have a single package in a dialog, this flexibility should still exist.

Where we have multiple packages in a dialog, and one package is reliant on the receipt of a response before generating a new INFO, then based on your comment about loss of an out of sequence request in a dialog, then all packages in that dialog will have to share that restriction.

Regards

Keith

> Sent: Wednesday, October 22, 2008 11:05 PM
> To: DRAGE, Keith (Keith)
> The reason for awaiting a reply before sending another INFO 
> is because if you don't do that, and the messages get 
> reordered, then the last one to arrive will fail due to CSeq 
> ordering. That's not a good thing, though I guess it would be 
> simple enough to retry it in that case.
> 
> I would assume that in most cases the actual order of 
> processing would not matter for different package types.
> 
> 	Thanks,
> 	Paul
> 
> >> IMO sending two info packages in separate INFO messages should 
> >> produce the same behavior as sending them in one.
> >> Except perhaps for order of processing. If we choose to define 
> >> sending two in one INFO, then I think we need to specify how the 
> >> ordering is supposed to work. (E.g. that they should be 
> processed in 
> >> the same order as they appear in the multipart, and that 
> in such case 
> >> the behavior MUST be the same as if they were sent in separate 
> >> messages in that order.)
> > 
> > Surely here you are implying that the two packages have a 
> dependency. That's two steps of use cases, i.e. that there is 
> a requirement for more than one use case in the first place, 
> and then the use case for the two packages being 
> interdependent in terms of data content.
> > 
> > If there is not such dependency, but the two packages both 
> require in order delivery for their own data, then surely 
> each package not sending the next INFO until it has received 
> the response for the previous one within its package is a 
> sufficient mechanism at the level of INFO and the body packaging.
> > 
> > Regards
> > 
> > Keith
> > 
> >> IMO sending two info packages in separate INFO messages should 
> >> produce the same behavior as sending them in one.
> >> Except perhaps for order of processing. If we choose to define 
> >> sending two in one INFO, then I think we need to specify how the 
> >> ordering is supposed to work. (E.g. that they should be 
> processed in 
> >> the same order as they appear in the multipart, and that 
> in such case 
> >> the behavior MUST be the same as if they were sent in separate 
> >> messages in that order.)
> >>
> >> The one advantage that comes to mind is that if you can't do this, 
> >> then you really need to wait for the round trip of one info before 
> >> sending another, which could be inconvenient and delay inducing if 
> >> you get the data for more than one at the same time.
> >>
> and leave 
> >> it till later to decide if sending multiple packages is useful.
> >>
> >> each containing one package provided the same solution as one INFO 
> >> containing two packages  (and assuming anyone has a use 
> case for two 
> >> packages on the same dialog - something I don't believe I have yet 
> >> seen presented to the list - did I miss it somewhere).
> >> whether we want one solution or two to be documented, and if one, 
> >> then which one.
> documentation to 
> >> provide.

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 23 Oct 2008 09:10:28 +0200

Hi Paul,

Now I understand what you mean - I mixed up things a little.

The question is: shall we really use the Info-Package header. And, if
so, shall we use it in the way as currently described by the draft?

Shouldn't we use Content-Type to indicate what is in the message body?
After all, we may need Content-Length etc.

So, there would be two options:

1. Use Content-Type to indicate info-package, and within the package
itself then indicate the exact package type

Example: Content-Type: application/info-package

2. Use Content-Type to indicate info-package AND exact package type

Example: Content-Type: application/info-package.foo

...or something like that.

Then, if you have multiple packages, you would use Content-Type:
multipart/mixed on the SIP level, and Content-Type
application/info-package within the mimes (normal multipart handling).

Regards,

Christer

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 22. lokakuuta 2008 16:36
To: Christer Holmberg
Cc: SIP IETF; Eric Burger
Subject: Re: [Sip] draft-ietf-sip-info-events-00: multiple packages per
INFO

My thinking was:

Answering that question is what led to my proposing the "multipart"
package.

	Thanks,
	Paul

> per INFO then you need to negotiate support for "multipart". Or maybe 
> we require support of multipart if you support any other package type.
> 
> 	Thanks,
> 	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 23 Oct 2008 09:14:31 +0200

Hi,

I think that the packages should have no dependency at all - and it's an
implementation issue in which order they are processed, etc.

So, IF the UAC really wants to ensure that package X is processed before
package Y, the UAC should send them in SEPARATE INFOs, and wait for the
X package INFO response before sending the Y package INFO.

Regards,

Christer

-----Original Message-----
From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
Sent: 23. lokakuuta 2008 0:46
To: Paul Kyzivat
Cc: Christer Holmberg; SIP IETF; Eric Burger
Subject: RE: [Sip] draft-ietf-sip-info-events-00: multiple packages per
INFO

> the same behavior as sending them in one.
> Except perhaps for order of processing. If we choose to define sending

> two in one INFO, then I think we need to specify how the ordering is 
> supposed to work. (E.g. that they should be processed in the same 
> order as they appear in the multipart, and that in such case the 
> behavior MUST be the same as if they were sent in separate messages in

> that order.)

Surely here you are implying that the two packages have a dependency.
That's two steps of use cases, i.e. that there is a requirement for more
than one use case in the first place, and then the use case for the two
packages being interdependent in terms of data content.

If there is not such dependency, but the two packages both require in
order delivery for their own data, then surely each package not sending
the next INFO until it has received the response for the previous one
within its package is a sufficient mechanism at the level of INFO and
the body packaging.

Regards

Keith

> the same behavior as sending them in one.
> Except perhaps for order of processing. If we choose to define sending

> two in one INFO, then I think we need to specify how the ordering is 
> supposed to work. (E.g. that they should be processed in the same 
> order as they appear in the multipart, and that in such case the 
> behavior MUST be the same as if they were sent in separate messages in

> that order.)
> sending another, which could be inconvenient and delay inducing if you

> get the data for more than one at the same time.
> 
> But we could certainly just decide not to define that now, and leave 
> containing two packages  (and assuming anyone has a use case for two 
> whether we want one solution or two to be documented, and if one, then

> which one.
> wherefore of those differences before deciding what documentation to 
> provide.
> > 
> > Regards
> > 
> > Keith
> >

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 23 Oct 2008 09:17:09 +0200

Hi, 

>We have one package per NOTIFY. Let's stick with one package per INFO,
unless we want to go back to using mime-types as the only distinguisher
of packages.

I raised that issue in another e-mail.

But, never the less, I have no strong feelings on the single versus
multiple package issue.

Regards,

Christer

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 23 Oct 2008 10:29:42 +0100

In reply to this whole thread, please bear in mind that we had lots of
discussion about whether it would be worthwhile defining this new INFO
mechanism, since existing applications are unlikely to change and the
best we can hope for is that new applications will exploit the new
mechanism. Therefore we want to keep the mechanism as simple as
possible. The complexities of matching body parts to header fields,
dealing with cases where only some of the packages are understood, etc.
are hardly likely to persuade people to implement the mechanism. Please
keep it simple.

John

> Sent: 23 October 2008 08:17
> To: Dean Willis; DRAGE, Keith (Keith)
> Cc: SIP IETF; Eric Burger; Paul Kyzivat

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 23 Oct 2008 11:51:20 +0200

Hi,

I agree with John. Let's keep it simple. If allowing multiple packages
in a single INFO causes issues, let's forget about it.

The whole idea with this is to allow people using INFO to do so in an
easy and standardized way, so let's not shoot ourselves in the foot with
complexity.

Regards,

Christer 

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: 23. lokakuuta 2008 12:30
To: Christer Holmberg; Dean Willis; DRAGE, Keith (Keith)
Cc: SIP IETF; Eric Burger; Paul Kyzivat
Subject: RE: [Sip] draft-ietf-sip-info-events-00: multiple packages per
INFO

John

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 23 Oct 2008 12:29:00 +0200

I don't have a problem agreeing with that.

Note that buried somewhere in this thread was a question of whether we
had a use case for multiple packages per dialog, or can we simplify even
further.

Keith 

> Sent: Thursday, October 23, 2008 10:51 AM
> To: Elwell, John; Dean Willis; DRAGE, Keith (Keith)
> I agree with John. Let's keep it simple. If allowing multiple 
> packages in a single INFO causes issues, let's forget about it.
> 
> The whole idea with this is to allow people using INFO to do 
> so in an easy and standardized way, so let's not shoot 
> ourselves in the foot with complexity.
> 
> Regards,
> 
> Christer 
> 
> In reply to this whole thread, please bear in mind that we 
> had lots of discussion about whether it would be worthwhile 
> defining this new INFO mechanism, since existing applications 
> are unlikely to change and the best we can hope for is that 
> new applications will exploit the new mechanism. Therefore we 
> want to keep the mechanism as simple as possible. The 
> complexities of matching body parts to header fields, dealing 
> with cases where only some of the packages are understood, etc.
> are hardly likely to persuade people to implement the 
> mechanism. Please keep it simple.
> 
> John
> 
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 23 Oct 2008 12:41:13 +0200

Hi, 

I don't think we should go that far, because that could become very
restrictive.

For example, assume I want to use INFO packages e.g. for DTMF during the
call setup, and then other INFO package(s) for something else during the
call.

Regards,

Christer

> Subject: RE: [Sip] draft-ietf-sip-info-events-00: multiple packages 
> per INFO
> 
> 
> Hi,
> 

> easy and standardized way, so let's not shoot ourselves in the foot 
> with complexity.
> 
> Regards,
> 
> Christer
> 
> Subject: RE: [Sip] draft-ietf-sip-info-events-00: multiple packages 
> per INFO
> 

> are hardly likely to persuade people to implement the mechanism. 
> Please keep it simple.
> 
> John
> 
>

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 23 Oct 2008 13:07:44 +0200

It may be restrictive, but will anyone notice the restriction?

Is there anyone out there who has a current use case for two packages
per dialog - rather than "I've definitely used one therefore want to
reserve my options in case I need a second"?

Keith

> Sent: Thursday, October 23, 2008 11:41 AM
> To: DRAGE, Keith (Keith); Elwell, John; Dean Willis
> had a use case for multiple packages per dialog, or can we 
> simplify even further.
> 
> I don't think we should go that far, because that could 
> become very restrictive.
> 
> For example, assume I want to use INFO packages e.g. for DTMF 
> during the call setup, and then other INFO package(s) for 
> something else during the call.
> 
> Regards,
> 
> Christer
> 
> 
> had lots of

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 23 Oct 2008 13:15:27 +0200

Hi, 

>It may be restrictive, but will anyone notice the restriction?

Maybe not today, but who knows about tomorrow.

I send DTMFs during call setup, and then you and me use some application
which use INFO during the call.

I don't have a more detailed use-case than that at the moment. But, I
don't think allowing many packages makes it more complex, and I really
think it is restrictive. Then, IF someone needs it, they will go on with
"legacy" usage, since they can't use info packages...

Regards,

Christer

> had a use case for multiple packages per dialog, or can we simplify 
> even further.
> 
> For example, assume I want to use INFO packages e.g. for DTMF during 
> the call setup, and then other INFO package(s) for something else 
> during the call.
> 
> Regards,
> 
> Christer
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 23 Oct 2008 08:06:40 -0400

Its not a matter of Info-Package *vs* Content-Type - Its Info-Package 
*plus* Content-Type. Previously there was an assumption that C-T would 
uniquely distinguish the "package". Read what Eric wrote about why that 
is a bad assumption.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 23 Oct 2008 08:13:12 -0400

I also agree it is too extreme to restrict to one package per dialog.
But as I stated earlier, I'm fine not defining multiple packages per INFO.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 23 Oct 2008 08:15:18 -0400

> reserve my options in case I need a second"?

ISUP + DTMF

Of course DTMF can be done other ways, but ...

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 23 Oct 2008 14:18:16 +0200

Hi, 

Fine.

But, what will the Content-Type value be, then? We need a value, and the
draft doesn't specify one.

OR, shall each info package define the Content-Type value, in addition
to the package name itself???

Regards,

Christer

Christer Holmberg wrote:
> stating which package it is. That was an alternative to Eric's 
> proposal that all the packages be listed at the outer level.
> 
> Then the question remained: in this case should there be an 
> Info-Package header at the outer level, and if so, what should it
contain?
> I guess an alternative would be for the Info-Package header at the 
> outer level to list all the packages contained, in no particular 
> order, and then for the individual parts to contain an Info-Package 
> describing that part.
> 
> I do think it is necessary for there to be an Info-Package header at 
> the outer level, to distinguish this from a legacy use of Info.
> 
> 	Thanks,
> 	Paul
> 
>> Regards,
>>
>> Christer
>>
>>
>>
>>  
>>

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 23 Oct 2008 14:48:59 +0100

I agree with Paul and Christer concerning multiple packages per dialog.
It seems a very reasonable thing to do and doesn't cost anything in
complexity.

John 

> Sent: 23 October 2008 13:13
> To: Christer Holmberg
> Cc: DRAGE, Keith (Keith); Elwell, John; Dean Willis; SIP 
> IETF; Eric Burger
> simplify even

---

From: Dean Willis <[email-masked]>
Date: Thu, 23 Oct 2008 09:15:18 -0500

> After all, we may need Content-Length etc.

Ah, no.

We had extended conversations on this earlier.  Content-Type tells you  
what's in the body; it just doesn't tell you what to DO with the body.

What, for example, is the purpose of an image/jpeg in an INFO?

--
dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 23 Oct 2008 09:19:32 -0500

> reserve my options in case I need a second"?

Two packages in the same dialog makes sense.  For example, one might  
want to use location-push and image-push during a call..

Different sets of packages allowed at different times during the  
lifespan of the dialog doesn't make nearly as much sense. The simplest  
model is to agree one set of packages "up front", and use only that  
set during the dialog.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 23 Oct 2008 10:20:25 -0400

> to the package name itself???

    7.2.4.  INFO Bodies

    Each Info Package MUST define what type or types of bodies are
    expected in INFO requests.  Such packages MUST specify or cite
    detailed specifications for the syntax and semantics associated with
    such a body.

    Info Packages also MUST define a default MIME type if the "Accept"
    header fails to define any MIME types in the INVITE request.
_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Thu, 23 Oct 2008 10:33:58 -0400

Dean Willis wrote:
> model is to agree one set of packages "up front", and use only that set 
> during the dialog.

No. I always have to remind people:

a 3pcc transfer can result in needing to renegotiate things in the 
dialog that remains.

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 23 Oct 2008 19:58:00 +0200

Wouldn't it be much simplier to define a generic mime, e.g. application/info-package, and then each info package only needs to define the Info-Package header value for that particular package?
 
Regards,
 
Christer

________________________________

From: Paul Kyzivat [mailto:[email-masked]]
Sent: Thu 23/10/2008 16:20
To: Christer Holmberg
Cc: SIP IETF; eric burger
Subject: Re: draft-ietf-sip-info-events-00: Content-Type vs Info-Package [was RE: [Sip] draft-ietf-sip-info-events-00: multiple packages per INFO]

    7.2.4.  INFO Bodies

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 23 Oct 2008 19:59:12 +0200

Hi,
 
>What, for example, is the purpose of an image/jpeg in an INFO?

That is not what I meant. 
 
We can use the Info-Package header, but can't we use a generic mime value - which tells us that there is an info package in the body.
 
Regards,
 
Christer

---

From: Dean Willis <[email-masked]>
Date: Thu, 23 Oct 2008 12:57:55 -0500

On Oct 23, 2008, at 9:33 AM, Paul Kyzivat wrote:

>> Two packages in the same dialog makes sense.  For example, one  
>> might want to use location-push and image-push during a call..
>> lifespan of the dialog doesn't make nearly as much sense. The  
>> simplest model is to agree one set of packages "up front", and use  
>> only that set during the dialog.
>

That's a dialog renegotiation, for all practical purposes a new dialog.

You're also negotiating new codecs, etc.

Doing INFO package renegotiation is just a part of it.

OTOH, I think we messed up with 3PCC, too. It's just another  
bottomless pit of complexity that we should have avoided.

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 23 Oct 2008 20:00:05 +0200

Hi,
 
Not only 3pcc, I think it could be useful to re-negotiate the packages during the session. For example, I may want DTMFs only during a certain period of the call, so for the rest of the call you would not be able to generate INFOs by pressing digit buttons.
 
Also, we may enable some application during the call, so the UAs need to re-negotiate the packages. For example, I may tell you that I have a vcard which I want to send you, but we may not have negotiated that "by defualt" when the call was established.
 
Regards,
 
Christer

From: Paul Kyzivat [mailto:[email-masked]]
Sent: Thu 23/10/2008 16:33
To: Dean Willis
Cc: DRAGE, Keith (Keith); Christer Holmberg; Elwell, John; SIP IETF; Eric Burger
Subject: Re: [Sip] draft-ietf-sip-info-events-00: multiple packages per INFO

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 23 Oct 2008 14:21:14 -0400

Christer,

I don't understand where you are heading with this?

If I want to send an INFO with a jpeg, then what is this other mime type 
doing other than getting in my way.

OTOH, we haven't discussed Content-Disposition wrt INFO. In the absence 
of any mention, I assume that "render" will be used for info packages, 
and the detailed processing defined by the Info-Package value.

In some sense, the Info-Package value is serving the same purpose as 
Content-Disposition. We could *consider* using the C-D *instead* of the 
Info-Package header, so that what we would be negotiating would be the 
acceptable C-D values. The downside of that is that we would then need 
to open up the registration of new C-D values. I think that might be 
opposed by a lot of people.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 23 Oct 2008 14:24:46 -0400

> Doing INFO package renegotiation is just a part of it.

That does not create a new dialog, it just updates the existing dialog. 
Its done using reINVITE or UPDATE. And that is exactly the currently 
proposed means of changing the set of packages in mid dialog.

> OTOH, I think we messed up with 3PCC, too. It's just another bottomless 
> pit of complexity that we should have avoided.

If we had invented Invite/Replaces early enough it could have replaced 
reINVITE. But that is water over the dam.

	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 23 Oct 2008 21:23:59 +0200

Hi,
 
Let's assume I want to send an INFO with package foo.
 
The value of the Info-Package header is "foo", right?
 
Now, what is the value of the Content-Type header?
 
Is it something which is generic for all info packages (e.g. application/info), OR is it something which is specified in the foo package description?
 
Regards,
 
Christer

From: Paul Kyzivat [mailto:[email-masked]]
Sent: Thu 23/10/2008 20:21
To: Christer Holmberg
Cc: Dean Willis; SIP IETF; Eric Burger
Subject: Re: [Sip] draft-ietf-sip-info-events-00: Content-Type vs Info-Package [was RE: draft-ietf-sip-info-events-00: multiple packages per INFO]

Christer,

        Thanks,
        Paul

---

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

> Now, what is the value of the Content-Type header?

The package could support a number of content types: image/jpeg, 
text/plain, multipart/related, ...
Anything that the definition of the package says is allowed.

At least that is how I think Eric intended to to be.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Thu, 23 Oct 2008 20:48:33 -0500

On Oct 23, 2008, at 12:58 PM, Christer Holmberg wrote:

> Wouldn't it be much simplier to define a generic mime, e.g.  
> application/info-package, and then each info package only needs to  
> define the Info-Package header value for that particular package?

No, as some packages might well send two bodies in a single INFO.

For example, envision a location-enabled image push: It sends an image/ 
jpeg and a pidf/lo that are correlated.

You need the Info-Package header to tell you what two bodies to look  
for and what they mean, and the MIME markup to know which is which.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 23 Oct 2008 20:50:59 -0500

On Oct 23, 2008, at 1:00 PM, Christer Holmberg wrote:

> Hi,
>
> Not only 3pcc, I think it could be useful to re-negotiate the  
> packages during the session. For example, I may want DTMFs only  
> during a certain period of the call, so for the rest of the call you  
> would not be able to generate INFOs by pressing digit buttons.
>
> Also, we may enable some application during the call, so the UAs  
> need to re-negotiate the packages. For example, I may tell you that  
> I have a vcard which I want to send you, but we may not have  
> negotiated that "by defualt" when the call was established.
>

then re-INVITE.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 23 Oct 2008 20:50:20 -0500

On Oct 23, 2008, at 12:59 PM, Christer Holmberg wrote:

> We can use the Info-Package header, but can't we use a generic mime  
> value - which tells us that there is an info package in the body.
>

Nope. Not only might you have multiple bodies per INFO, you might have  
several different MIME types that might be usable with a given info- 
package.

For example, an image push app might use image/jpeg, image/gif, image/ 
raw, etc. The package defines which type or types are allowed.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 24 Oct 2008 00:02:49 -0400

Dean,

I'm now confused on what you are advocating.

As its currently written, you can negotiate which packages you want to 
use. The later in the call you can renegotiate to use different ones. 
That seems consistent with what you are saying. So what is the issue?

	Thanks,
	Paul

Dean Willis wrote:
>> Not only 3pcc, I think it could be useful to re-negotiate the packages 
>> during the session. For example, I may want DTMFs only during a 
>> certain period of the call, so for the rest of the call you would not 
>> be able to generate INFOs by pressing digit buttons.
>>
>> Also, we may enable some application during the call, so the UAs need 
>> to re-negotiate the packages. For example, I may tell you that I have 
>> a vcard which I want to send you, but we may not have negotiated that 
>> "by defualt" when the call was established.
>>
> 
> then re-INVITE.
> 
> -- 
> Dean
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 24 Oct 2008 06:22:15 +0200

Hi,

>> negotiated that "by defualt" when the call was established.

Yes.
 
Where you thinking of something else?
 
Regards,
 
Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 24 Oct 2008 08:21:07 +0200

Hi,

(I've put all text about this into a single reply)

Dean:
=====

>>>We had extended conversations on this earlier.  Content-Type tells 
>>>you what's in the body; it just doesn't tell you what to DO with the 
>>>body.
>>>

[Christer] If we assume that we are NOT going to allow multiple packages
per INFO (nobody has objected to that restriction) we wouldn't have that
problem.

Paul:
=====

>At least that is how I think Eric intended to to be.

[Christer] I agree that a package could be associated with a number of
content types. But, since the Info-Package header shows which package is
included, I just wonder why we can't use a common C-T mime.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 24 Oct 2008 08:07:15 -0400

Pruned. Comments inline.

> included, I just wonder why we can't use a common C-T mime.

Just because there is only one package per info, there still could be 
*alternative* C-Ts for a given package. If you use one C-T for all INFOs 
then you can't do this. And its an abuse of the C-T, since then it won't 
describe the format of the content.

I do think there is something we haven't discussed: how do we figure out 
what part of the overall body is the part that carries the package? 
Normally this is no issue, since it is the entire body of the INFO 
message. But there are cases where it might not be. For instance if 
S/MIME is used, or if there is some header in the message the needs to 
reference a body part from a CID URI.

The answer to this goes back to Content-Disposition. The body part that 
contains the info package should have a unique C-D. That can be 
"render", or we could pick some other one.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 24 Oct 2008 14:15:59 +0200

Hi, 

>I do think there is something we haven't discussed: how do we 
>figure out what part of the overall body is the part that 
>carries the package? 
>Normally this is no issue, since it is the entire body of the 
>INFO message. But there are cases where it might not be. For 
>instance if S/MIME is used, or if there is some header in the 
>message the needs to reference a body part from a CID URI.
> 
>The answer to this goes back to Content-Disposition. The body 
>part that contains the info package should have a unique C-D. 
>That can be "render", or we could pick some other one.

I believe the mime rules are something like:

--boundary
Mime-headers
Empy-line
Content (SDP, info packet, etc)
--boundary--

For SIP, the ruleas are:

SIP-part
Empty-line
Message body (SDP, info packet - or one of more mimes).

I guess the question is whether we should define some generic syntax for
the info packages, e.g. Something which identifies the beginning of an
info package.

For SDP, you find the beginning by looking for the v= parameter.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 24 Oct 2008 08:42:25 -0400

Christer,

For SDP, you find the part by looking for the one with 
Content-Disposition:session. If there is a part with no C-D header then 
one with a C-T of application/sdp defaults to "session". So its all 
about C-D.

	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 24 Oct 2008 14:47:12 +0200

Hi, 

>Content-Disposition:session. If there is a part with no C-D 
>header then one with a C-T of application/sdp defaults to 
>"session". So its all about C-D.

The C-D header gives you information about the body, yes, but I don't
think it helps you to FIND the body.

That's what the SIP and MIME ABNFs are for.

Regards,

Christer

> 
> 	Paul
> 
> Christer Holmberg wrote:
> > Hi,
> > 
> >> I do think there is something we haven't discussed: how do 
> we figure 
> >> out what part of the overall body is the part that carries the 
> >> package?
> >> S/MIME is used, or if there is some header in the message 
> the needs 
> >> to reference a body part from a CID URI.
> >>
> >> The answer to this goes back to Content-Disposition. The body part 
> >> that contains the info package should have a unique C-D.
> > I guess the question is whether we should define some 
> generic syntax 
> > for the info packages, e.g. Something which identifies the 
> beginning 
> > of an info package.
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 24 Oct 2008 09:12:17 -0400

Oops, I just realized I didn't state this the way I meant...

> one with a C-T of application/sdp defaults to "session". So its all 

For *offers and answers* you find the part by looking for the one with 
Content-Disposition:session. If there is a part with no C-D header then 
  one with a C-T of application/sdp defaults to "session". So its all 
about C-D. (In theory, application/sdp is just one of the C-Ts that 
might be used to encode offers and answers.)

>     Paul
> 
> Christer Holmberg wrote:
>> Hi,
>>> I do think there is something we haven't discussed: how do we figure 
>>> package? Normally this is no issue, since it is the entire body of 
>>> the INFO message. But there are cases where it might not be. For 
>>> instance if S/MIME is used, or if there is some header in the message 
>>> the needs to reference a body part from a CID URI.
>>>
>>> that contains the info package should have a unique C-D. That can be

---

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

Oh, sorry. I didn't really mean "find". I meant "choose the appropriate 
body part".

	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 24 Oct 2008 22:53:21 +0200

Hi,
 
(Combining e-mails again)

Paul:
====

>Oh, sorry. I didn't really mean "find". I meant "choose the appropriate body part".

>might be used to encode offers and answers.)
 
I am not sure what you mean by "body part". Is this a problem if we only allow a single info-package per message?
 
Regards,
 
Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 24 Oct 2008 17:10:32 -0400

> I am not sure what you mean by "body part". Is this a problem if we only allow a single info-package per message?

I mean, even with INFO the body may contain more than the info package, 
or it may contain something that is not the info package and contain 
*no* info package. For instance, it might contain a body that is 
referenced via a CID: URI in some header in the message, that serves 
some incidental purpose.

The body could be a multipart/mixed, and one part could contain the info 
package, and some other part could contain the info package.

Thinking that the body must contain only the info package is failing to 
remember the lessons we have already learned with INVITE and other messages.

So no, this has nothing to do with multiple info packages per message. I 
have stopped talking about that.

	Thanks,
	Paul

---

From: Dean Willis <[email-masked]>
Date: Fri, 24 Oct 2008 16:26:39 -0500

One might renegotiate on a re-INVITE, or on any transaction. I believe  
Christer was proposing the latter. I think restricting INFO package  
negotiation to dialog-forming and dialog-reforming transactions is  
reasonable.

--
Dean

On Oct 23, 2008, at 11:02 PM, Paul Kyzivat wrote:

> As its currently written, you can negotiate which packages you want  
> to use. The later in the call you can renegotiate to use different  
> ones. That seems consistent with what you are saying. So what is the  
> issue?
>
> 	Thanks,
> 	Paul
>
> Dean Willis wrote:
>>> during a certain period of the call, so for the rest of the call  
>>> you would not be able to generate INFOs by pressing digit buttons.
>>>
>>> need to re-negotiate the packages. For example, I may tell you  
>>> that I have a vcard which I want to send you, but we may not have

---

From: Dean Willis <[email-masked]>
Date: Fri, 24 Oct 2008 16:28:03 -0500

> included, I just wonder why we can't use a common C-T mime.

Then which of the multiple bodies, each of which carries the same C-T  
mime marking, is which? Are you relying on ordering?

--
Dean

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 24 Oct 2008 23:24:43 +0200

Hi,

>have stopped talking about that.

So, just to make sure I understand: you are talking about a case where the INFO does contain a multipart message body, but only one of the mimes contains an actual info-package (the other mime(s) contains something else)?
 
Example:
 
Content-Type:multipart/mixed
Info-Package: foo
 
--boundary
 
foo data
 
--boundary
 
some other (non-info package) data
 
--boundary--

Regards,
 
Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 24 Oct 2008 23:32:42 +0200

Hi,
 
>> content types. But, since the Info-Package header shows which 
>> package is included, I just wonder why we can't use a common C-T mime.
>>
>

Let's assume BOTH bodies contain C-T: image/jpeg. How do you know which is associated with the info package?
 
Regards,
 
Christer

---

From: Dean Willis <[email-masked]>
Date: Fri, 24 Oct 2008 16:36:28 -0500

On Oct 24, 2008, at 4:32 PM, Christer Holmberg wrote:

> Let's assume BOTH bodies contain C-T: image/jpeg. How do you know  
> which is associated with the info package?
>

So you have a multipart body, with one or more parts related to an  
INFO package, and other parts related to something else, such as AIB,  
E2M, etc. Right?

The content-disposition of the body parts related to INFO packages  
needs to differentiate them from the other body parts.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 24 Oct 2008 18:04:46 -0400

> So, just to make sure I understand: you are talking about a case where the INFO does contain a multipart message body, but only one of the mimes contains an actual info-package (the other mime(s) c…

pretty much. And to distinguish those, you need more than C-T.
But I think as we have been discussing, if we only allow one info 
package per INFO, then the Info-Package header belongs in the message, 
not in the body part.

I'll revise your example a bit:

INFO sip:[email-masked]
To:...
From:...
Some-Header: CID:abcdefg
Info-Package: foo
Content-Length:...

--boundary
Content-Type: application/foo-data
Content-Disposition: package;handling=required

foo data
--boundary
Content-ID: abcdefg
Content-Type: application/some-header-data
Content-Disposition: by-reference;handling=optional

In the above I have used C-D of "package" to identify the part that 
contains the info package. That is yet to be determined, but I think it 
needs to be well defined, even if it is "render".

A more straightforward case would be:

INFO sip:[email-masked]
To:...
From:...
Info-Package: foo
Content-Type: application/foo-data
Content-Disposition: package;handling=required
Content-Length:10

foo data

---

From: Dean Willis <[email-masked]>
Date: Fri, 24 Oct 2008 17:36:35 -0500

On Oct 24, 2008, at 5:04 PM, Paul Kyzivat wrote:

>
> Christer Holmberg wrote:
>
>> So, just to make sure I understand: you are talking about a case  
>> where the INFO does contain a multipart message body, but only one  
>> of the mimes contains an actual info-package (the other mime(s)  
>> contains something else)?
>
> package per INFO, then the Info-Package header belongs in the  
> message, not in the body part.
>

So the error condition is you have two body parts of types allowed for  
the INFO package, but only one of them is the "real" info, and the  
other part is from some other extension.

If it hurts, don't do it?

Seriously, a Content-Disposition would sort this out.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 24 Oct 2008 19:28:46 -0400

Dean Willis wrote:
>>> where the INFO does contain a multipart message body, but only one of 
>>> the mimes contains an actual info-package (the other mime(s) contains 
>>> something else)?
>>
> the INFO package, but only one of them is the "real" info, and the other 
> part is from some other extension.
> 

Yes. We need a C-D.

It can be "render" if we want it to be. But I think that brings some 
baggage that we could do without. In particular, "render" is the default 
C-D for any C-T that isn't defined to have some other C-D as its default.

I am really now thinking that the info package type is really a 
"sub-disposition-type" - an extension to the disposition type namespace 
that is independently managed. And then we provide the means to 
negotiate use of those in INFO.

	Paul

---

From: Jeroen van Bemmel <[email-masked]>
Date: Sat, 25 Oct 2008 14:09:53 +0200

Multiple packages per INFO can trivially be supported by defining a 
Content-Type parameter to indicate the INFO event package being used, 
instead of the "Info-Package" header

So:

INFO sip:[email-masked]
To:...
From:...

--boundary
Content-Type: application/foo-data*;info-package=foo*

foo data
--boundary
Content-ID: abcdefg

I believe this models things better, as the INFO event package being 
used is really just an attribute of the Content-Type to help 
interpretation of the contents, just like Content-Type helps interpret 
the format

Regards,
Jeroen

Elwell, John wrote:
>>>> Note that buried somewhere in this thread was a question 
>>>>         
>> of whether we
>>     
>>> For example, assume I want to use INFO packages e.g. for 
>>>       
>> DTMF during the
>>     
>>> call setup, and then other INFO package(s) for something 
>>>       
>> else during the
>>     
>>> call.
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>>
>>>       
>>>> I agree with John. Let's keep it simple. If allowing 
>>>>         
>> multiple packages
>>     
>>>> The whole idea with this is to allow people using INFO to 
>>>>         
>> do so in an 
>>     
>>>> easy and standardized way, so let's not shoot ourselves in 
>>>>         
>> the foot 
>>     
>>>> with complexity.
>>>>
>>>> Regards,
>>>>
>>>> Christer
>>>>
>>>> discussion about whether it would be worthwhile defining 
>>>>         
>> this new INFO
>>     
>>>> mechanism, since existing applications are unlikely to 
>>>>         
>> change and the 
>>     
>>>> possible. The complexities of matching body parts to 
>>>>         
>> header fields, 
>>     
>>>>> Subject: Re: [Sip] draft-ietf-sip-info-events-00: 
>>>>>           
>> multiple packages 
>>     
>>>>> per INFO
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>>           
>>>>>>> Why does putting two different packages in the same INFO
>>>>>>>               
>>>>> work better
>>>>>           
>>>>>>> than two different INFO messages each with their own
>>>>>>>               
>>>>> package usage? Is
>>>>>
>>>>>           
>>>>>>> there a desirable relationship that can be implemented
>>>>>>>               
>>>>> between the two
>>>>>
>>>>>           
>>>>>> We have one package per NOTIFY. Let's stick with one package
>>>>>>             
>>>>> per INFO,
>>>>> But, never the less, I have no strong feelings on the 
>>>>>           
>> single versus 
>>     
>>>>> multiple package issue.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Christer
>>>>>
>>>>>

---

From: Jeroen van Bemmel <[email-masked]>
Date: Sat, 25 Oct 2008 14:31:34 +0200

A possible reason to want multiple packages per INFO request, is that it 
allows one to construct applications that rely on "all or nothing" 
semantics for correlated events.

For example, if one would use SIP to implement an application that lets 
one post a small icon on a blog, and requires an authorization token to 
do that, both would have to arrive together. Another example could be an 
electronic variant of a postage stamp (i.e. some token representing some 
monetary value), when using two different INFOs one might fail to arrive 
where the other would (i.e. content without payment, or payment without 
content).

It has to do with certain atomic, transactional behavior and consistency 
of the user experience

Regards,
Jeroen

Paul Kyzivat wrote:
>>> The whole idea with this is to allow people using INFO to do so in 
>>> an easy and standardized way, so let's not shoot ourselves in the 
>>> foot with complexity.
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>> mechanism, since existing applications are unlikely to change and 
>>> the best we can hope for is that new applications will exploit the 
>>> new mechanism. Therefore we want to keep the mechanism as simple as

---

From: Salvatore Loreto <[email-masked]>
Date: Sat, 25 Oct 2008 18:58:08 +0300

what happens if an application includes in a multiple packaged INFO 
request a body part the Sever does not understand?
how is the server able to indicate that only a part of the INFO request 
was not understood ?

regards
Sal

Jeroen van Bemmel wrote:
> A possible reason to want multiple packages per INFO request, is that 
> it allows one to construct applications that rely on "all or nothing" 
> For example, if one would use SIP to implement an application that 
> lets one post a small icon on a blog, and requires an authorization 
> token to do that, both would have to arrive together. Another example 
> could be an electronic variant of a postage stamp (i.e. some token 
> representing some monetary value), when using two different INFOs one 
> might fail to arrive where the other would (i.e. content without 
> payment, or payment without content).
>
> It has to do with certain atomic, transactional behavior and 
> consistency of the user experience
>
> Regards,
> Jeroen
>
> Paul Kyzivat wrote:
>>> even
>>> the
>>>>> But, never the less, I have no strong feelings on the single 
>>>>> versus multiple package issue.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Christer
>>>>>
>>>>>

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 26 Oct 2008 11:52:57 +0100

Hi,
 
I don't understand why we should have to make an assumption that the C-D value will be different, and that it will always be possible to pick out the info package based on it. 
 
We don't know what info packages there will be, and we don't have a clear picture of other usages, so I think making such restrictive assumption is really bad. In that case I would rather prefer that we don't even allow multipart in INFO, which may also be another shooting in the feet thing...
 
I would still like to understand why the proposed usage of C-T by Jeroem and myself (eventhough I may not have made myself clear) wouldn't work:
 
example: Content-Type: application/foo-data;info-package=foo 
 
I don't think the C-T usage, as in the example above, fits into Eric's why-content-type-is-bad description.
 
image/jpge is BAD, I agree
 
image/jpeg; info-package=foo is not bad, in my opinion.
 
Of course, there may still be a need for C-D, per mime, but I don't think we should use C-D in order to figure out which mime is associated with the info package (unelss we have a C-D value of "info-package", that is).
 
Regards,
 
Christer

From: Paul Kyzivat [mailto:[email-masked]]
Sent: Sat 25/10/2008 01:28
To: Dean Willis
Cc: SIP IETF; Christer Holmberg
Subject: Re: [Sip] draft-ietf-sip-info-events-00: Content-Type vs Info-Package [was RE: draft-ietf-sip-info-events-00: multiple packages per INFO]

Yes. We need a C-D.

        Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 26 Oct 2008 12:01:24 +0100

Hi,

>package per INFO, then the Info-Package header belongs in the message,
 
I don't think that defining Info-Package as a mime header would even be within the scope of the SIP WG, would it?
 
My assumption has been that the I-P header is in the SIP message part, and that causes the problem: in the case of multipart, how to associate the correct mime with the I-P header? I still think making assumptions on C-D is very dangerous, considering the very little experience we have of the C-D header in the first place.

>needs to be well defined, even if it is "render".

Again, I don't think using C-D for the "association" is a good idea.

>Content-Disposition: package;handling=required

...assuming that we don't allow multipart in INFOs, yes.
 
Regards,
 
Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 26 Oct 2008 12:07:48 +0100

>how is the server able to indicate that only a part of the INFO request

THAT is what you ARE supposed to use the C-D header for. If handling=required, and the receiver doesn't understand it, rejected the message shall be...
 
Regards,
 
Christer

---

From: Jeroen van Bemmel <[email-masked]>
Date: Sun, 26 Oct 2008 12:38:16 +0100

Christer,

Like I wrote before: adding the INFO package as a parameter to 
Content-Type solves all this. I don't think C-D is the right header, 
because the "disposition" would depend on the semantics of the event 
package. We simply need an additional qualifier to disambiguate the 
interpretation of the body

Regards,
Jeroen

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 26 Oct 2008 12:51:32 +0100

Hi,

>interpretation of the body

Dude, I agree with you :)
 
Regards,
 
Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 26 Oct 2008 15:00:38 -0400

> interpretation of the body

If you mentioned this before I missed it.

Its an interesting idea. But I don't think it is technicallyh feasible.
AFAIK the parameters to a C-T must be defined as part of the definition 
of the C-T. That wold mean that only yet-to-be-defined C-Ts could be 
used for info packages.

Whether C-D is suitable to identifhy the info package depends on whether 
it makes any sense to use C-D as an independent control over processing 
of the package, in addition to the definition of the package itself. I 
certainly haven't seen it that way. I would need a good use case to 
convince me that it is a useful thing to do.

	Thanks,
	Paul

>> I don't think that defining Info-Package as a mime header would even 
>> be within the scope of the SIP WG, would it?
>>  
>> My assumption has been that the I-P header is in the SIP message part, 
>> and that causes the problem: in the case of multipart, how to 
>> associate the correct mime with the I-P header? I still think making 
>> assumptions on C-D is very dangerous, considering the very little 
>> experience we have of the C-D header in the first place.
>>
>>

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Mon, 27 Oct 2008 01:44:33 +0100

Should we even allow bodies that do not relate to info packages in INFO
messages (legacy issues excepted).

If I had a SDP offer to send at the same time as a body for an info
package, I suspect I would be told to send one in a reINVITE and the
other in an INFO, rather than combine them in a single message.

Whatever the answer to this question, I guest the draft would need a
paragraph to cover it.

Regards

Keith

> Behalf Of Dean Willis
> Sent: Friday, October 24, 2008 10:36 PM
> To: Christer Holmberg
> Cc: SIP IETF; Paul Kyzivat
> Content-Type vsInfo-Package [was RE: 
> draft-ietf-sip-info-events-00: multiplepackages per INFO]
> 
> 
> >>> [Christer] I agree that a package could be associated 
> with a number 
> >>> of content types. But, since the Info-Package header shows which

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 26 Oct 2008 21:05:54 -0400

> messages (legacy issues excepted).

I think we must allow it. The use case I have in mind is when there is a 
header in the message that contains a URI, and the desire is to use a 
CID URI referencing a  body part in the message. (To avoid the need to 
have or access a separate server.

An example of this would be a Geolocation header. (Although the draft 
for that seems to have expired.)

I don't know if that precise case makes practical sense, but its an 
example of a general mechanism we have that should not be excluded.

Another example (though improbable) is an S/MIME body.

> other in an INFO, rather than combine them in a single message.

Yes, it is certainly true that sending a SDP for purposes of O/A is 
inappropriate in INFO.

> Whatever the answer to this question, I guest the draft would need a

Yes, I agree.

	Thanks,
	Paul

---

From: Dean Willis <[email-masked]>
Date: Mon, 27 Oct 2008 02:09:41 -0500

> example: Content-Type: application/foo-data;info-package=foo

You think the MIME people are going to approve this?

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Mon, 27 Oct 2008 02:14:09 -0500

> messages (legacy issues excepted).

Probably have to, given things like AIB and E2M . . .

Not that those are actually deployed, of course.

--
Dean

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 27 Oct 2008 08:23:04 +0100

Hi, 

>>>because the "disposition" would depend on the semantics of 
>>>the event package. We simply need an additional qualifier to
disambiguate the 
>>AFAIK the parameters to a C-T must be defined as part of the 
>>definition of the C-T. That wold mean that only 
>>yet-to-be-defined C-Ts could be used for info packages.

That would be a reason to use a COMMON C-T type, and then a parameter
which identifies the info package.

Let's keep in mind that info packages have been NEGOTIATED. Ie I will
not send you a package unless you have indicated support for it.

Therefor, if I send you a picture, I don't think it matters if C-T is
image/jpeg, or application/info;info-package=jpeg-package.

...because, YOU know the semantics of the package. Also, since an info
package is not supposed to change the core SIP state, the stack itself
doesn't need to know the semantics of the body, does it?

The problem is if I send you ONLY image/jpeg - without any negotiation,
and semantics we both have agreed on. I don't know what you will do it.
I think THAT is the problem that Eric initially raised.

Regards,

Christer

> >> My assumption has been that the I-P header is in the SIP message 
> >> part, and that causes the problem: in the case of 
> multipart, how to 
> >>> contains the info package. That is yet to be determined, 
> but I think 
> >>> it needs to be well defined, even if it is "render".
> >>>     
> >>
> >>> Content-Disposition: package;handling=required Content-Length:10
> >>>
> >>> foo data
> >>>     
> >>

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 27 Oct 2008 08:24:46 +0100

>>You think the MIME people are going to approve this?

Dunno. Maybe they would approve Content-Type:
application/info;info-package=foo

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 27 Oct 2008 08:21:19 -0400

> I don't think that defining Info-Package as a mime header would even be within the scope of the SIP WG, would it?

Before I say more, I will first point out that discussion is irrelevant 
if we only intend to allow one info package per INFO.

But MIME bodies are extensible with arbitrary headers. I don't recall if 
there is any requirement about standardizing them.

> My assumption has been that the I-P header is in the SIP message part, and that causes the problem: in the case of multipart, how to associate the correct mime with the I-P header?

Lets not get off in the weeds discussing this until and unless we decide 
to support multiple info packages per INFO.

> I still think making assumptions on C-D is very dangerous, considering the very little experience we have of the C-D header in the first place.

Could you please spell out precisely what your concern is?

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 27 Oct 2008 08:34:56 -0400

> I think THAT is the problem that Eric initially raised.

So you are suggesting that *all* info packages share a single C-T, 
except for parameters to it. But then that single C-T may be used with a 
range of C-D types???

This seems like it would be quite inconvenient for the use case here. If 
there is to be an info package where I can send you a picture for some 
purpose, then the info package must specify the precise format of the 
picture (equivalent of C-T) because the C-T will be this fixed value. 
There may be a bunch of different C-Ts that are useful for encoding my 
picture, but I'll need a separate info package for each. And I'll need 
to fudge my encoding/decoding logic to no longer work based on C-T in 
this case.

IMO what I am suggesting is much simpler and more straightforward. A 
single C-D type identifies which body part should be processed as the 
"payload" of the INFO message. (In a way entirely analogous to the way 
the C-D of "session" identifies the payload of INVITE.) The C-T of this 
payload identifies how it is encoded, and the value from the 
Info-Package header is used to demultiplex the payload across all the 
possible ways that INFO can be used.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 27 Oct 2008 14:44:23 +0100

Hi, 

>>>>>Content-Type solves all this. I don't think C-D is the right 
>>>>>header, because the "disposition" would depend on the semantics of 
>>>>>disambiguate the interpretation of the body
>>>>definition of the C-T. That wold mean that only yet-to-be-defined 
>>>>C-Ts could be used for info packages.
>> 
>>Let's keep in mind that info packages have been NEGOTIATED. 
>>Ie I will not send you a package unless you have indicated support for
it.

>>The problem is if I send you ONLY image/jpeg - without any 
>>negotiation, and semantics we both have agreed on. I don't 
>>know what you will do it. I think THAT is the problem that Eric
initially raised.
>So you are suggesting that *all* info packages share a single C-T,
except for parameters to it.

Yes.

>But then that single C-T may be used with a range of C-D types???

Yes.

>This seems like it would be quite inconvenient for the use 
>case here. If there is to be an info package where I can send 
>you a picture for some purpose, then the info package must 
>specify the precise format of the picture (equivalent of C-T) 
>because the C-T will be this fixed value. 
>There may be a bunch of different C-Ts that are useful for 
>encoding my picture, but I'll need a separate info package 
>for each. And I'll need to fudge my encoding/decoding logic 
>to no longer work based on C-T in this case.
> 
>IMO what I am suggesting is much simpler and more 
>straightforward. A single C-D type identifies which body part 
>should be processed as the "payload" of the INFO message. (In 
>a way entirely analogous to the way the C-D of "session" 
>identifies the payload of INVITE.) The C-T of this payload 
>identifies how it is encoded, and the value from the 
>Info-Package header is used to demultiplex the payload across 
>all the possible ways that INFO can be used.

I am just wondering whether the C-D mechanism is 100% waterproof.

Or, are you proposing an info specific C-D type? "Info" for example?

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 27 Oct 2008 14:48:44 +0100

Hi, 

>>>>So, just to make sure I understand: you are talking about 
>>>>a case where the INFO does contain a multipart message body, 
>>>>but only one of the mimes contains an actual info-package 
>>>>(the other mime(s) contains something else)?
>>>I don't think that defining Info-Package as a mime header 
>>>would even be within the scope of the SIP WG, would it?
> 
>Before I say more, I will first point out that discussion is 
>irrelevant if we only intend to allow one info package per INFO.

I think it's irrelevant if we only intent to allow one MIME per INFO.

Because, IF you have multipart, and one of them contains the info
package, the question is how to figure out which it is.

>But MIME bodies are extensible with arbitrary headers. I don't recall
if there is any requirement about standardizing them.

Well, if we could put the Info-Package header into the mime itself we
obviously won't have a problem.

>>multipart, how to associate the correct mime with the I-P header?
> 
>Lets not get off in the weeds discussing this until and 
>unless we decide to support multiple info packages per INFO.
> 
>>I still think making assumptions on C-D is very dangerous, considering
the very little experience we have of the C-D 
>>header in the first place.
> 

You have multipart.

One mime contains the info package.

One mime contains something else.

My concern is that, by looking at the C-D you will always be able to
determine which mime contains the info package.

...again, unless you specify a info specific C-D value.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 27 Oct 2008 10:06:26 -0400

> I think it's irrelevant if we only intent to allow one MIME per INFO.

I think it is irrelevant if we only allow one info package per INFO, 
even if we allow multipart bodies where one of those is the info package.

> package, the question is how to figure out which it is.

Yes, we then require a way to distinguish which part is the info 
package. Hopefully we can find a way better than using the Info-Package 
header in the body part to do that.

> obviously won't have a problem.

I'd rather not have to be searching all the body parts to that extent to 
figure it out. The advantage of C-D is that its already necessary to 
look at that to figure out the role of each body part.

> ...again, unless you specify a info specific C-D value.

Indeed, IMO there *must* be a C-D value that, *in INFO messages*, is 
used *only* for the info package body part.

My preference would be for a new value, say "package", "info", or 
"info-package". I think we *might* be able to define that "render" 
serves this purpose *for INFO messages*, but I would rather not do that 
because it is indeed asking from trouble and confusion.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 27 Oct 2008 19:22:44 +0100

Hi, 

>>>>> I don't think that defining Info-Package as a mime header would 
>>>>> even be within the scope of the SIP WG, would it?
even if we allow multipart bodies where one of those is the info
package.
>
>I'd rather not have to be searching all the body parts to that extent
to figure it out. The advantage of C-D is that its already necessary to
look at that to figure out the role of each body part.

You will have to look through "all" (not sure there will be too many...)
body parts anyway. Even if the info package happens to be in the "first"
body part you look at, you still need to look through the rest if there
are body parts with handling=required etc. That is normal multipart
handling.

IF we define a new C-D value, which is unique for info packages, I have
no problem with a C-D based solution. 

But, it would still be more work to define info packages, because you
would need to specify which C-T value to use. Maybe not a big issue if
you can use an existing value, but it's more work if you have to define
a new value. For example, is there a standardized value which could be
used for DTMF? Has Cisco registerd the value they use in C-T when
sending DTMFs? :)

My issue is if we want to re-use an existing value, because I don't
think we for sure can say that couldn't be a case where more than one
body part has a "render" value (or whatever existing value we would
choose for info packages).

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 27 Oct 2008 14:52:04 -0400

Pruning out a lot...

Christer Holmberg wrote:

> body parts anyway.

If implementing for the general case, it will at least be a loop over 
parts of a multipart/mixed, if present, and possibly recursion.

> Even if the info package happens to be in the "first"

See Dale's document with a process oriented take on the C-D stuff.
In general, every UA is going to have to implement that general 
framework for processing body parts, independent of method.

What we are talking about here is potentially another search *in 
addition* to that. Admittedly its not a huge deal, but it starts to mess 
up modularity of implementation.

> no problem with a C-D based solution. 

OK. That is progress!!!

> would need to specify which C-T value to use.

The document already calls for this:

    7.2.4.  INFO Bodies

The wording could be better. There are no explicit IANA considerations 
about registering an INFO package. Its just implied here. Its a little 
confusing here what is intended to be part of the *definition* of a new 
package vs. what is intended to be in the content of a particular 
package instance in an INFO message.

> Maybe not a big issue if
> a new value.

If you need to do that, then so be it.

> For example, is there a standardized value which could be

I don't know, but I doubt it.

> choose for info packages).

This is all hypothetical, because we don't have any usages with the new 
info package stuff.

What I guess you are getting at is if there are any existing uses of 
body parts with "render" that might have to coexist with the info 
package in the message. I agree that is a potential problem, since for 
instance people rarely put C-D for a multipart itself, thus defaulting 
to "render".

So I agree, we need a new value.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 27 Oct 2008 21:48:07 +0100

Hi, 

>>>serves this purpose *for INFO messages*, but I would rather not do 
>>>that because it is indeed asking from trouble and confusion.
>> 
>>IF we define a new C-D value, which is unique for info packages, I
have no problem with a C-D based solution.
>    header fails to define any MIME types in the INVITE request.

Yes, it's in the document. The point was that one may have to define
this new MIME type. But, maybe that is not a big problem (I haven't
defined mime types, so I can't tell).

about registering an INFO package. Its just implied here. Its a little
confusing here what is intended to be part of the 
>*definition* of a new package vs. what is intended to be in the content
of a particular package instance in an INFO message.

We do need to have a section on what needs to be part of an info package
definition. The mime type is one thing, for sure.

I guess we should also look at what/if we can re-use from SIP events.

We also need to decide whether info packages should have a version
number system. From experience I think that would be very useful.

Info-Package: foo-package;version=1

info package stuff.

Exactly.

package in the message.

Yes.

>So I agree, we need a new value.

Good :)

Regards,

Christer

---

From: "Nasir Khan" <[email-masked]>
Date: Wed, 29 Oct 2008 00:45:56 -0400

Maybe it warrants a separate thread but I would like to discuss section
7.1.3 of this draft where 3265 is talked about as an alternative.
Since we are talking about the notion of well defined info packages and the
INFO messages
will carry information as a result of an event like an ISUP event or DTMF
event (the name of the draft itself has "event" in it), then the two User
Agents can very well subscribe to these events and use the notifications for
the information exchange.
This will automatically inherit all the good work done around notification
framework and will lay to rest lot of questions and perhaps save some
re-invention.

Regards
Nasir

-- 
Get the most comprehensive open source SIP testing framework at
http://sipper.agnity.com

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 29 Oct 2008 09:58:18 -0400

I'm not certain I understand the point you are making.
Is it that we don't need info events because we could accomplish the 
same thing using subscriptions to suitable event packages?

If that is your point, we have been down that path already. Many of us 
have taken that position in the past (and may still believe it today), 
but there were many arguments that that approach is to heavy weight. 
Evidence of that is the continued use of info for DTMF even though we 
have an event package for that.

	Paul

Nasir Khan wrote:
> Since we are talking about the notion of well defined info packages and 
> the INFO messages
> will carry information as a result of an event like an ISUP event or 
> DTMF event (the name of the draft itself has "event" in it), then the 
> two User Agents can very well subscribe to these events and use the 
> notifications for the information exchange.
> This will automatically inherit all the good work done around 
> notification framework and will lay to rest lot of questions and perhaps 
> save some re-invention.
>  
> Regards
> Nasir
> 
> On Mon, Oct 27, 2008 at 4:48 PM, Christer Holmberg 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
> 
> 
>     Hi,
> 
>      >    7.2.4. <http://7.2.4./>  INFO Bodies
>      >
>     Use [email-masked]
>     <mailto:[email-masked]> for questions on current sip
>     Use [email-masked] <mailto:[email-masked]> for new developments
>     on the application of sip
> 
> 
> 
> 
> -- 
> ------------------------------------------------------------------------
>

---

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

Correct.

On Oct 23, 2008, at 4:07 PM, Paul Kyzivat wrote:

>> Is it something which is generic for all info packages (e.g.  
>> application/info), OR is it something which is specified in the foo  
>> package description?
>> Regards,
>> Christer
>> Subject: Re: [Sip] draft-ietf-sip-info-events-00: Content-Type vs  
>> Info-Package [was RE: draft-ietf-sip-info-events-00: multiple  
>> packages per INFO]
>> Christer,
>>> We can use the Info-Package header, but can't we use a generic  
>>> mime value - which tells us that there is an info package in the  
>>> body.
>>>
>>> Regards,
>>>
>>> Christer

---

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

Channeling Keith here: is there a real use case for package versioning?

I cannot imagine backwards-compatible packages. Once one starts  
changing the stuff in an INFO package, it is a different package. That  
is, rather than

    Info-Package: foo-package;version=1
    Info-Package: foo-package;version=2

You, in reality have:

    Info-Package: foo-package
    Info-Package: something-like-foo-but-not-really-foo-anymore

This is more especially so when one considers there is no possibility  
of negotiating package versions, whereas there is a possibility of  
negotiating different packages.

For the one instance one could come up with in theory for needing  
versioning, remember one does get to have an arbitrary parameter:

    Info-Package: foo-package               /* Version 1 */
    Info-Package: foo-package;bar        /* Version 2 */

Is this latter mechanism sufficient?

Yet another poll:

[ ] We must have abstract versioning as part of the Info Framework  
document

[ ] We do not need to have abstract versioning, as it does not do  
anything for anyone

[ ] We do not need abstract versioning, but it would be worthwhile  
including some text,
     like what is above, to show people how to do it.

[ ] Something else? _____________________________________

On Oct 27, 2008, at 4:48 PM, Christer Holmberg wrote:

> [snip]
[snip]

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 31 Oct 2008 00:45:03 -0400

> Yet another poll:
> 
> [ ] We must have abstract versioning as part of the Info Framework document
> 
> [x] We do not need abstract versioning, but it would be worthwhile 
> including some text,

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 31 Oct 2008 13:59:22 +0100

Hi,

Before I give my vote, I just want to clarify a little what I meant.

Assume you have package A, which can carry some information.

Then you figure out you need a new information element, but all the old
information still remains exactly the same. You create package B.

Now, package B would be fully backward compatible with package A.

But, if there is no versioning, and backward compability guidelines, I would
have to indicate explicit support of both package A and B.

Of course, if package B is NOT backward compatible, it would have to be a
compeltely new package.

Another option is of course to deal with these kind of things inside the
info packet itself.

Regards,

Christer

> From: Eric Burger [mailto:[email-masked]] 
> Sent: 30. lokakuuta 2008 18:53
> To: Christer Holmberg
> Cc: SIP IETF
> Subject: Info Package Versioning
> 
> I cannot imagine backwards-compatible packages. Once one 
> starts changing the stuff in an INFO package, it is a 
> different package. That is, rather than
> 
> This is more especially so when one considers there is no 
> possibility of negotiating package versions, whereas there is 
> a possibility of negotiating different packages.
> 
> For the one instance one could come up with in theory for 
> needing versioning, remember one does get to have an 
> arbitrary parameter:
> 
> [ ] We do not need to have abstract versioning, as it does 
> not do anything for anyone
> 
> [ ] We do not need abstract versioning, but it would be 
> worthwhile including some text,
> > We do need to have a section on what needs to be part of an info 
> > package definition. The mime type is one thing, for sure.
> >

---

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

Ditto.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Paul Kyzivat
Sent: Thursday, October 30, 2008 11:45 PM
To: Eric Burger
Cc: SIP IETF; Christer Holmberg
Subject: Re: [Sip] Info Package Versioning

---

From: Eric Burger <[email-masked]>
Date: Fri, 31 Oct 2008 11:24:51 -0400

I'm leaning toward "inside the INFO packet", or, ad hoc. My reasoning  
is if Y is X with a little more, if you advertise Y, would X  
understand it? X would probably say, "hmmm - version greater than me,  
so I should reject it." That doesn't help.

On the other hand, if you are on the XML bandwagon, you could always  
have backwards compatible stuff in your schema.