Subject: [sipcore] Query on draft-ietf-sipcore-info-events-07

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Sat, 13 Mar 2010 13:26:58 +0800

Hi all

Are there any registered INFO packages and can the regular SIP event
packages based on RFC 3265 be used with INFO mechanism?

Thanks

Regards
Ranjit

---

From: Adam Roach <[email-masked]>
Date: Sat, 13 Mar 2010 16:53:06 -0600

Please don't cross-post to dispatch and sipcore.

On 3/12/10 23:26, Mar 12, Avasarala Ranjit-A20990 wrote:
>
> Are there any registered INFO packages
>

Not yet.

> and can the regular SIP event packages based on RFC 3265 be used with 
> INFO mechanism?
>

Absolutely not. No. Never. Under no circumstances. Nein, ???, ????, Non, 
Nej. They are _completely_ different things.

Really, if this is somehow unclear in the INFO draft, we need to pull it 
from publication request and work on it some more. It would be the worst 
possible outcome if implementors were led to believe that 3265 packages 
could be used with INFO. Where did you get the impression that this 
might be okay?

/a

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Sun, 14 Mar 2010 16:03:50 +0800

Hi Adam
 
From the latest version of the info draft-ietf-sipcore-info-events-07, the section 4 "Info Packages" does not talk about the kind of packages and their format. 
 
Though the section 7.4.1.2  talks that use of SUBSCRIBE / NOTIFY based on 3265 as an alternate mechanism, it is not clear what should be the format of a typical INFO package. 
 
Also further Section 7.4.1.3 mentions the usage of SIP MESSAGE method. So does this mean I can use MESSAGE method as an alternative to INFO? 
 
Thanks
Regards 
Ranjit 

________________________________

From: Adam Roach [mailto:[email-masked]] 
Sent: Sunday, March 14, 2010 4:23 AM
To: Avasarala Ranjit-A20990
Cc: [email-masked]
Subject: Re: [sipcore] Query on draft-ietf-sipcore-info-events-07

Not yet.

	and can the regular SIP event packages based on RFC 3265 be used with INFO mechanism?

Absolutely not. No. Never. Under no circumstances. Nein, Нет, नहीं, Non, Nej. They are _completely_ different things.

Really, if this is somehow unclear in the INFO draft, we need to pull it from publication request and work on it some more. It would be the worst possible outcome if implementors were led to believe that 3265 packages could be used with INFO. Where did you get the impression that this might be okay?

/a

---

From: Eric Burger <[email-masked]>
Date: Sun, 14 Mar 2010 13:26:48 -0400

The point of Section 7.4 is there is often a far superior method of doing user-user signaling besides INFO. For example, if you want to send DTMF digits, use KPML (he says modestly).

There is absolutely NO correspondence between an Info Package and an Event Package. Moreover, if someone tried to register such, my guess is they would not get the requisite Specification Required level needed to register a package.

On Mar 14, 2010, at 4:03 AM, Avasarala Ranjit-A20990 wrote:

> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Mon, 15 Mar 2010 01:34:36 +0800

Hi Eric and all,

Then what is the real purpose of an INFO package? Is there any example or use case where I would use an INFO package over SIP MESSAGE? Also if the INFO package is going to take the format of an XML document (I think), then how different would that be from the regular event packages?

One more query I have is : say in case the UAC does not include the Recv-Info header in the initial INVITE request, then can it still use INFO with package with mid session INFO message?

Thanks

Regards
Ranjit

---

From: Eric Burger <[email-masked]>
Date: Sun, 14 Mar 2010 20:01:52 -0400

SOME people think session management for SUBSCRIBE/NOTIFY is too hard, especially if the lifetime of the user-user exchange exactly matches the lifetime of the SIP dialog.

Simplicity and laziness?

Ah - MESSAGE (I was thinking SUBSCRIBE). Problem is you have no way of knowing whether the receiver wants to digest what you're sending.

When you say UAC for the INVITE, I presume you mean the UAC for the INFO, as well? If so, it is the UAS that must offer a Recv-Info header. What the UAC offers is irrelevant, unless the UAC wants to advertise what the UAC is willing to receive from the UAS.  All of that should be in the text.

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Mon, 15 Mar 2010 14:28:17 +0800

Ok. Say if I want to write a INFO package for a particular purpose, what should be the format of that package? Should it be an XML one like the event packages? Then what would be the procedures for that package - like the UAC that intends to send a particular session or application level information generates the corresponding INFO package and sends it?

E.g  UAC sends INVITE to UAS with Recv-Info: app-info
     ...............................................
     UAC sends INFO (app-info package)

 will app-info package be something like this

 <xml version="1.0" ?>
  .................
  <app-info>
    ...
  </app-info>
 </xml>

Thanks 

Regards
Ranjit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Burger
Sent: Monday, March 15, 2010 5:32 AM
To: Avasarala Ranjit-A20990
Cc: SIPCORE SIPCORE
Subject: Re: [sipcore] Query on draft-ietf-sipcore-info-events-07

Simplicity and laziness?

---

From: Adam Roach <[email-masked]>
Date: Mon, 15 Mar 2010 09:53:44 -0500

> Ah - MESSAGE (I was thinking SUBSCRIBE). Problem is you have no way of knowing whether the receiver wants to digest what you're sending.

That's one problem.

The key problem is that MESSAGE means something. And that something is 
not "here's a pile of bits, figure out what to do with them." The 
meaning is "here is some kind of media that you need to present to your 
user."

For non-media payloads consumed by automata, you need something with 
different semantics.

/a

---

From: Adam Roach <[email-masked]>
Date: Mon, 15 Mar 2010 10:26:40 -0500

[as participant]

On 3/15/10 01:28, Mar 15, Avasarala Ranjit-A20990 wrote:
> Ok. Say if I want to write a INFO package for a particular purpose, what should be the format of that package? Should it be an XML one like the event packages?

Not all event packages are XML -- see RFC 3842, for example. The format 
that is best suited for conveying information in a MIME body generally 
depends on what you're trying to convey. People seem to like XML for 
this kind of thing, but there is nothing preventing any appropriate data 
format.

> Then what would be the procedures for that package

If you want to publish an INFO package as part of the IETF process, you 
really need to step through section 7 -- and, in particular, section 7.4 
-- and explain why INFO is the right tool for the task you have in mind. 
You need to explain why the other mechanisms designed for inter-automata 
communication don't suit the purpose of the application you're 
designing. Describe why, for example, you want to use INFO instead of 
SUBSCRIBE and NOTIFY.

To be clear, you can define INFO packages outside the IETF process, as 
long as you do so in a way that can be referenced and which is 
effectively permanent. This would typically involve working with another 
SDO, although a company, organization, or individual could, in theory, 
publish a specification as well (as long as it met the criteria 
described in section 11.4 of the INFO draft).

In either case, you'll need to include enough information to allow 
interoperable implementation. Although it's not the only way to do 
things, the easy way to do this would be to include the following 12 
sections in your document, with contents as suggested by the 
corresponding parts of Section 10 of the INFO framework:

      1.  General
      2.  Overall Description
      3.  Applicability
      4.  Info Package Name
      5.  Info Package Parameters
      6.  SIP Option Tags
      7.  INFO Message Body Parts
      8.  Info Package Usage Restrictions
      9.  Rate of INFO Requests
      10. Info Package Security Considerations
      11. Implementation Details
      12. Examples

>   - like the UAC that intends to send a particular session or application level information generates the corresponding INFO package and sends it?
>

Except that it wouldn't be something as generic as "app-info." You'd 
need to define an info package that specified what kind of information 
is to be conveyed, and how the recipient processes it. Ideally, your 
event package name would reflect that application in some way.

You'll need a formal (and complete) definition of the body syntax. If 
you choose to use XML, this would be something like a DTD, Schema, or 
Relax NG definition. If you use some other data framework (e.g., ASN.1), 
you'll need to define your fields using the formal definition language 
provided by that framework. If you're rolling your own syntax, you 
probably want to use something like ABNF.

But I'm pretty much just repeating the guidance provided by the INFO 
draft itself. I would suggest a careful, detailed reading -- with 
special attention to sections 7 and 10 (and their respective subsections).

/a

---

From: Robert Sparks <[email-masked]>
Date: Thu, 18 Mar 2010 14:45:11 -0500

Its worth looking to see if the document text is as explicit as people think it should be on this point.

Also, I remember some discussion about whether it's ok to reuse event package names? (Is it ok for someone to create a "dialog" event package for instance?)
The draft is silent on this at the moment - is that on purpose?

RjS

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 22 Mar 2010 17:28:38 +0100

Hi,
 
>Also, I remember some discussion about whether it's ok to reuse event package names? (Is it 
>ok for someone to create a "dialog" event package for instance?)

I see no reason to explicitly forbid it, since we're dealing with different namespaces.

But, people may of course use common sense and ask themselves whether it's a smart thing to do...

Regards,

Christer

	

	Not yet.

	
	
	/a

---

From: Adam Roach <[email-masked]>
Date: Mon, 22 Mar 2010 10:54:47 -0700

> I see no reason to explicitly forbid it, since we're dealing with different namespaces.

I agree.

In fact, I believe that doing anything that implies that they're drawing 
from the same namespace is actually harmful: doing so can convey the 
incorrect impression that there might be some way to use an Event 
Package in INFO, or an INFO package in SUBSCRIBE.

/a

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Wed, 24 Mar 2010 00:33:57 +0800

Hi

Now since the I-D does not specify any particular format or template for
an INFO package, there is a very likely chance that someone could
propose an INFO package as a XML package which is quite similar to an
3265 based event package. Now how can someone prevent use of this
package with SUBSCRIBE / NOTIFY?

Regards
Ranjit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adam Roach
Sent: Monday, March 22, 2010 11:25 PM
To: Christer Holmberg
Cc: [email-masked]; Avasarala Ranjit-A20990
Subject: Re: [sipcore] Query on draft-ietf-sipcore-info-events-07

On 3/22/10 9:28 AM, Christer Holmberg wrote:
>
> Hi,
>
>    
>> Also, I remember some discussion about whether it's ok to reuse event

>> package names? (Is it ok for someone to create a "dialog" event 
>> package for instance?) The draft is silent on this at the moment - is
that on purpose?

I agree.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 23 Mar 2010 17:51:13 +0100

Hi, 

>Now since the I-D does not specify any particular format or template for an INFO package, 
>there is a very likely chance that someone could propose an INFO package as a XML package 
>which is quite similar to an
>3265 based event package. Now how can someone prevent use of this package with SUBSCRIBE / 
>NOTIFY?

Technically you can use the same MIME message bodies both for INFO packages and event packages, but if you want to use the message body as part of an event package you need to register that event package.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: Monday, March 22, 2010 11:25 PM
To: Christer Holmberg
Cc: [email-masked]; Avasarala Ranjit-A20990
Subject: Re: [sipcore] Query on draft-ietf-sipcore-info-events-07

that on purpose?

I agree.

In fact, I believe that doing anything that implies that they're drawing from the same namespace is actually harmful: doing so can convey the incorrect impression that there might be some way to use an Event Package in INFO, or an INFO package in SUBSCRIBE.

/a

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 23 Mar 2010 20:25:40 +0100

You cannot prevent it, because IETF are not the protocol police.

However if you wish to make a claim of conformance to both the event package specifications and the info package specifications, you will have to implement each using an appropriately registered descriptor of the package. Presumably expert review on either path will raise some issues with you trying to do this, unless you demonstrate that what you are doing actually makes sense, rather than just providing two ways of using the protocol to do the same thing.

regards

Keith 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Avasarala Ranjit-A20990
> Sent: Tuesday, March 23, 2010 4:34 PM
> To: Adam Roach; Christer Holmberg
> Cc: [email-masked]
> Now since the I-D does not specify any particular format or 
> template for an INFO package, there is a very likely chance 
> that someone could propose an INFO package as a XML package 
> 3265 based event package. Now how can someone prevent use of 
> this package with SUBSCRIBE / NOTIFY?
> 
> Regards
> Ranjit
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adam Roach
> In fact, I believe that doing anything that implies that 
> they're drawing from the same namespace is actually harmful: 
> doing so can convey the incorrect impression that there might 
> be some way to use an Event Package in INFO, or an INFO 
> package in SUBSCRIBE.
> 
> /a