Subject: [sipcore] Requesting the publication of the draft-ietf-sipcore-info-events

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 14 Jan 2010 13:28:57 +0200

Hi,

we intend to request the publication of this draft next week. If there 
is no further comments on the draft, we will ask the authors to fix the 
references problems reported by the ID nits tool below and we will be 
requesting the publication of that revision.

http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-sipcore-info-events-04.txt

Thanks,

Gonzalo
SIPCORE co-chair

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 14 Jan 2010 14:40:44 +0100

I have no further comments.

John 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Gonzalo Camarillo
> Sent: 14 January 2010 11:29
> To: SIPCORE
> Subject: [sipcore] Requesting the publication of the 
> draft-ietf-sipcore-info-events
> 
> Hi,
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Robert Sparks <[email-masked]>
Date: Thu, 14 Jan 2010 15:09:18 -0600

I just skimmed -04 and see a few of things to pay attention to.

1) The IANA considerations section is confusing. If I remember the  
conversation
correctly, the group settled on "Specification Required". That's what  
the document
should say.

2) I agree with Paul's BNF observation (I tried to point to that in my  
review of -01)

3) The document still requires putting Recv-INFO in an OPTIONS request.
      I continue to believe this is useless and should be removed.

I think my other concerns have been addressed, but I haven't checked the
minor/nit ones closely.

Has anyone other than the authors reviewed the tables?

RjS

On Jan 14, 2010, at 5:28 AM, Gonzalo Camarillo wrote:

> Hi,
>
> we intend to request the publication of this draft next week. If  
> there is no further comments on the draft, we will ask the authors  
> to fix the references problems reported by the ID nits tool below  
> and we will be requesting the publication of that revision.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 Jan 2010 16:13:23 -0500

> Has anyone other than the authors reviewed the tables?

Casually - enough to notice the issue I pointed out.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 Jan 2010 19:44:52 -0500

>      I continue to believe this is useless and should be removed.

I agree, but the problem is bigger than this draft.

The whole concept that OPTIONS will tell you the capabilities of the UA 
is pretty broken - it assumes those are stable over time and are context 
free, which is often not the case. There are almost never any guarantees 
that the info you receive from OPTIONS will still be true if you try to 
act on it.

The concept that the response code from OPTIONS should be the same as 
you would get were you to send an INVITE is even more broken. It doesn't 
work at all well for UAs that don't support INVITE.

The definition of OPTIONS needs some serious rework.

	Thanks,
	Paul

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 15 Jan 2010 09:58:03 +0200

Hi Paul,

> The definition of OPTIONS needs some serious rework.

yes, this has come up several times in the past. When people try to use 
OPTIONS to provide a meaningful service, they fairly soon notice how 
broken it is. At some point, it could be interesting to gather a few 
requirements and try to fix it somehow.

Cheers,

Gonzalo

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 15 Jan 2010 09:12:40 +0100

Hi,

So, what do I do? Change mandatory to optional?

Regards,

Christer

> Sent: 15. tammikuuta 2010 9:58
> To: Paul Kyzivat
> Cc: SIPCORE
> Subject: [sipcore] OPTIONS requests WAS (Re: Requesting the 
> publication of the draft-ietf-sipcore-info-events)
> 
> Hi Paul,
> 
> > The whole concept that OPTIONS will tell you the 
> capabilities of the 
> > UA is pretty broken - it assumes those are stable over time and are 
> > context free, which is often not the case. There are almost 
> never any 
> > guarantees that the info you receive from OPTIONS will 
> still be true 
> > if you try to act on it.
> > 
> > you would get were you to send an INVITE is even more broken. It 
> > doesn't work at all well for UAs that don't support INVITE.
> > 
> yes, this has come up several times in the past. When people 
> try to use OPTIONS to provide a meaningful service, they 
> fairly soon notice how broken it is. At some point, it could 
> be interesting to gather a few requirements and try to fix it somehow.
> 
> Cheers,
> 
> Gonzalo
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 15 Jan 2010 10:32:30 +0200

Hi Christer,

the reason I had changed the subject of the thread was to keep 
discussions on the info events draft and on the possibility to work on 
fixing OPTIONS separate ;o)

People appreciate having the right subjects on the right threads when 
they have to go back to the archives to look for something.

Cheers,

Gonzalo

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 15 Jan 2010 09:39:02 +0100

Sorry. I thought you changed the subject in order to discuss the specific OPTIONS comments given for the info draft.

Regards,

Christer 

> From: Gonzalo Camarillo 
> Sent: 15. tammikuuta 2010 10:33
> To: Christer Holmberg
> Cc: Paul Kyzivat; SIPCORE
> Subject: Re: [sipcore] OPTIONS requests WAS (Re: Requesting 
> the publication of the draft-ietf-sipcore-info-events)
> 
> Hi Christer,
> 
> the reason I had changed the subject of the thread was to 
> keep discussions on the info events draft and on the 
> possibility to work on fixing OPTIONS separate ;o)
> 
> People appreciate having the right subjects on the right 
> threads when they have to go back to the archives to look for 
> something.
> 
> Cheers,
> 
> Gonzalo
> 
> Christer Holmberg wrote:
> >  
> > Hi,
> > 
> >> yes, this has come up several times in the past. When 
> people try to 
> >> use OPTIONS to provide a meaningful service, they fairly 
> soon notice 
> >> how broken it is. At some point, it could be interesting 
> to gather a 
> >> few requirements and try to fix it somehow.
> >>
> >> Cheers,
> >>
> >> Gonzalo
> >>

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 15 Jan 2010 11:17:45 +0100

There is not a lot of point in adding to something that is already broken, so I tend to agree with Robert. I had not commented on this in the past, but I never saw a lot of use for Recv-Info in OPTIONS (I just saw it as harmless), but given the concerns voiced by Robert and Paul I would avoid adding to the known problem.

John 

> [mailto:[email-masked]] On Behalf Of Christer Holmberg
> Sent: 15 January 2010 08:39
> To: Gonzalo Camarillo
> Cc: SIPCORE
> Sorry. I thought you changed the subject in order to discuss 
> the specific OPTIONS comments given for the info draft.
> 
> Regards,
> 
> Christer 
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 15 Jan 2010 13:27:32 +0100

Hi,

>1) The IANA considerations section is confusing. If I 
>remember the conversation correctly, the group settled on 
>"Specification Required". That's what the document should say.

Section 11.4, which describes the content of the registrary, contains a bullet which says:

"o  Reference: A reference to a specification which describes the Info Package."

---------------

>2) I agree with Paul's BNF observation (I tried to point to 
>that in my review of -01)

Please se my reply to Paul.

---------------

>3) The document still requires putting Recv-INFO in an 

I have changed it to optional, and modified the text in section 4.4 to:

"...the UA MAY include Recv-Info header field in the message..."

Or, is that still too much? Do you want to remove section 4.4?

Regards,

Christer

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 15 Jan 2010 14:27:29 +0100

> Sent: 15 January 2010 12:28
> To: Robert Sparks; Gonzalo Camarillo
> Cc: SIPCORE
> Subject: Re: [sipcore] Requesting the publication of the 
> draft-ietf-sipcore-info-events - Robert's comments
> 
>  
> Hi,
> 
[JRE] Well, if you do choose to include it, what does it mean to the recipient? Isn't it simpler to remove it altogether?

John

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 15 Jan 2010 09:16:28 -0500

> So, what do I do? Change mandatory to optional?

Works for me.

	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 15 Jan 2010 15:19:44 +0100

Hi, 
 
>>>3)The document still requires putting Recv-INFO in an OPTIONS 
>>>request.
>> 
>[JRE] Well, if you do choose to include it, what does it mean 
>to the recipient? Isn't it simpler to remove it altogether?

I can do that. 

I would like to keep the "o" in table 6.1, though, in order to not disallow it, when we in future have "fixed" OPTIONS.

Regards,

Christer

---

From: Robert Sparks <[email-masked]>
Date: Fri, 15 Jan 2010 09:07:26 -0600

>>> Or, is that still too much? Do you want to remove section 4.4?

That's my preference. I have had conversations with others that
think having the value appear in a response might be reasonable.
The group should express some consensus here.
Again, I think the section should be deleted.

> I would like to keep the "o" in table 6.1, though, in order to not  
> disallow it, when we in future have "fixed" OPTIONS.

If the group decides to remove the section, that's an inappropriate  
thing to do.
There is already text in the base spec that talks about how elements  
should be robust and ignore headers showing
up where they shouldn't. Having a "-" in this table would not  
constrain future specs from making it allowed.
That same "fixed" OPTIONS can modify the table when it's appropriate  
for the message to appear.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 15 Jan 2010 10:31:22 -0500

I previously indicated I was ok with making this optional in OPTIONS.
But I'm ok with excluding it from OPTIONS too. Regardless, in practice 
I'm going to recommend that implementors ignore it in the response to 
OPTIONS.

	Paul

Robert Sparks wrote:
> up where they shouldn't. Having a "-" in this table would not constrain 
> future specs from making it allowed.
> That same "fixed" OPTIONS can modify the table when it's appropriate for 
> the message to appear.
> 
>>
>> Regards,
>>
>> Christer
>

---

From: Robert Sparks <[email-masked]>
Date: Fri, 15 Jan 2010 09:37:48 -0600

> "o  Reference: A reference to a specification which describes the  

"Specification Required" is a special string that is easy for IANA to  
recognize.

The section should contain this sentence:

"The registration policy for this document is Specification Required  
[RFC5226]."

It does not need to try to explain what Specification Required means.  
RFC5226 does that.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 15 Jan 2010 22:25:55 +0100

Hi, 

>But I'm ok with excluding it from OPTIONS too. Regardless, in practice I'm going to recommend that implementors ignore it in the response to OPTIONS.

I'll remove the section and change it to "-" in the table.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 15 Jan 2010 22:32:35 +0100

Hi, 

>That's my preference. I have had conversations with others that think having the value appear in a response might be reasonable.

Gone it will be.

>>[JRE] Well, if you do choose to include it, what does it mean to the 
>>recipient? Isn't it simpler to remove it altogether?
>
>I can do that.
>
>If the group decides to remove the section, that's an inappropriate thing to do.
>There is already text in the base spec that talks about how elements should be robust and ignore headers showing up where they shouldn't. Having a "-" in this table would not constrain future specs from 
>making it allowed.
>That same "fixed" OPTIONS can modify the table when it's appropriate for the message to appear.

I will modify it to "-" in the table.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 15 Jan 2010 22:52:32 +0100

Hi,

>>> conversation correctly, the group settled on "Specification 
>>> Required". That's what the document should say.
>>

I did propose the section text on the list, and nobody objected. 

Anyway, if I understand you correctly, I will replace the existing paragraph about IANA assigning an expert ect with your text above?

So, the section would look become:

-------------------------

11.4.  Creation of the Info Packages Registry

   Please create a subregistry in the SIP Parameters registry for Info
   Packages.

   The registration policy for this document is Specification Required  
   [RFC5226].

   The following data elements populate the Info Package Registry.
   o  Info Package Name: The Info Package Name is a case insensitive
      token.  In addition, IANA shall not register multiple Info Package
      names that have identical case-insensitive values.
   o  Reference: A reference to a specification which describes the Info
      Package.

   The initial population of this table shall be:

   Name         Reference

-------------------------

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 15 Jan 2010 22:55:36 +0100

Hi, 

>There is not a lot of point in adding to something that is already broken, so I tend to agree with Robert. I had not commented on this in the past, but I never saw a lot of use for Recv-Info in OPTIONS 
>(I just saw it as harmless), but given the concerns voiced by Robert and Paul I would avoid adding to the known problem.

Personally I think what I was trying to do was actually to fix the OPTIONS problem, but adding explicit text for how the header field is used with OPTIONS.

No matter how much we "fix" OPTIONS, I think there will still be a need to describe how it is used for specific header fields (maybe not all header fields).

But, regard that as a side note. I will remove the section :)

Regards,

Christer

> Subject: Re: [sipcore] OPTIONS requests WAS (Re: Requesting the 
> Sorry. I thought you changed the subject in order to discuss the 
> specific OPTIONS comments given for the info draft.
> 
> Regards,
> 
> Christer
> 
> > Subject: Re: [sipcore] OPTIONS requests WAS (Re: Requesting the 
> > discussions on the info events draft and on the possibility to work 
> > on fixing OPTIONS separate ;o)
> > 
> > People appreciate having the right subjects on the right threads 
> > when they have to go back to the archives to look for something.
> > 
> > Cheers,
> > 
> > Gonzalo
> > 
> > Christer Holmberg wrote:
> > >  
> > > Hi,
> > >

---

From: Robert Sparks <[email-masked]>
Date: Fri, 15 Jan 2010 16:09:00 -0600

What you have below looks correct to me except for one nit (which is  
my fault - sorry).
It should say "policy for this registry" instead of "policy for this  
document".

Thanks,

RjS

On Jan 15, 2010, at 3:52 PM, Christer Holmberg wrote:

>>> Section 11.4, which describes the content of the registrary,  
>>> contains
>>> a bullet which says:
>>>
>>> "o  Reference: A reference to a specification which describes the  
>>> Info
>>> Package."
>>
> Anyway, if I understand you correctly, I will replace the existing  
> paragraph about IANA assigning an expert ect with your text above?
>

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 16 Jan 2010 20:18:46 +0100

Hi,

>It should say "policy for this registry" instead of "policy for this

Is it ok to say "THE registry"?

Regards,

Christer

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 19 Jan 2010 16:22:32 +0200

Hi Paul and Gonzalo,

I completely agree with the fact that the OPTIONS method to discovery 
capabilities is pretty broken and then
it is not useful to provide a meaningful service.

In order to write down some requirements, lets consider the scenario 
where Alice wants to discover the Bob device capabilities

- Capabilities
here a first possible requirements could be:

    Req.: The returned capabilities to an OPTIONS request should reflect
    what Bob is able to communicate with Alice with respect
       to what are the capabilities of his fleet of devices, not just
    one device.

at present when Alice sends a SIP OPTIONS request to discover the Bob 
capabilities,
if Bob ha registered two or more UAs, then the OPTIONS request forks and 
arrive to all the registered UAs;
however the proxy performing the forking forwards back to Alice only the 
first response it receives.

Preferably  the  capability discovery mechanism should let Alice (or 
rather Alices device) know if Bob can take audio on one device,
but video, video and text on his other visual friendly device.
If a capability discovery mechanism is able to provide that level of 
granularity, it helps Alice's device understand that while on a
voice session with Bob, it is no way a re-INVITE to video would work, 
but instead her device should send a new video-session INVITE
towards Bob allowing hi to press the 'yes' button on the visual device. 
Thus, there would be two parallel sessions between Alice and Bob,
one for voice and the second one for video/text/picture.
A capability discovery mechanism like this would also provide the 
context for capabilities, where as Paul points out in his mail at moment
with the currents OPTIONS request capabilities are context free.

- Time
The capabilities should not be considered stable over time, however they 
can be regarded as stable (but without any guarantees) if an INVITE take 
places within short time.
The latter is often the the intent of the querying party I would assume. 
Thus, Alice wants to communicate with Bob "now" but first wants to check
"what" Bob can do. That is why she sends an OPTIONS. Soon as she knows 
the capabilities, she immediately invokes a compatible (to the 
capabilities received)
communication manner.

Cheers
Sal

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 19 Jan 2010 11:31:01 -0500

>       to what are the capabilities of his fleet of devices, not just

That may be in conflict with the original intent and design of OPTIONS.
Note that one of the things you are explicitly permitted to do is 
restrict the hop count so that OPTIONS stops before reaching its final 
address. In that case, whatever has it when it runs out of hops is 
supposed to answer.

That says to me that whoever does respond to OPTIONS should be 
responding for itself.

In the case where the request is addressed to an AOR, and there is a 
proxy responsible for that AOR, that will typically route requests via 
contact routing, its not entirely clear what it means to answer for itself.

> first response it receives.

That *may* be what happens.

> but video, video and text on his other visual friendly device.

That would be a nice thing to be able to learn.
Whether OPTIONS is the way to achieve that is an entirely different 
question.

What would you do? Have the proxy send *new* OPTIONS to each registered 
device and then consolidate the results? Would that entail a 
multipart/alternative containing SDP from each contact?

> towards Bob allowing hi to press the 'yes' button on the visual device. 

I think Alice needs more information before concluding that.
It may be that those two devices reside in Bob's multiple offices, one 
in Boston and the other in San Jose.

Also, Alice then needs a way of directing the new INVITE to the intended 
destination. (Perhaps callerprefs would meet this need, perhaps not.)

> with the currents OPTIONS request capabilities are context free.

If people think this is worth doing, we could no doubt come up with a 
way of doing it. But it seems unlikely that OPTIONS would be the whole 
answer. (Realistically it probably makes more sense to leave OPTIONS 
alone and create something new.)

> the capabilities, she immediately invokes a compatible (to the 

That may be a reasonable goal. But it probably requires some more 
examination into the reasons that capabilities might change over time.
For instance, if Bob's device is handling a call when it receives the 
query, does the response reflect what it can do concurrently with that 
call, or what it will be able to do once that call has ended? (Both may 
be useful pieces of information.)

	Thanks,
	Paul

>>> The whole concept that OPTIONS will tell you the capabilities of the 
>>> context free, which is often not the case. There are almost never any 
>>> guarantees that the info you receive from OPTIONS will still be true 
>>> if you try to act on it.
>>>
>> yes, this has come up several times in the past. When people try to 
>> use OPTIONS to provide a meaningful service, they fairly soon notice 
>> how broken it is. At some point, it could be interesting to gather a

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 21 Jan 2010 15:17:37 +0200

Hi Paul,

thanks for the answer and the useful comments.
I'll try to write down a mail for Dispatch wg,
to check what people would like to do:
put some serious effort to better specify the definition of OPTIONS method,
or if for them make more sense to leave OPTIONS alone and create 
something new.

cheers
Sal

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 21 Jan 2010 14:43:42 +0100

Hi,

We can of course clarify the generic procedures for OPTIONS. But, I think there is always going to be a need to describe how OPTIONS is applied to specific header fields, message body MIMEs etc, as I tried to do in the Info draft.

Regards,

Christer 

> [mailto:[email-masked]] On Behalf Of Salvatore Loreto
> Sent: 21. tammikuuta 2010 15:18
> To: Paul Kyzivat
> Cc: SIPCORE; Gonzalo Camarillo
> I'll try to write down a mail for Dispatch wg, to check what 
> people would like to do:
> put some serious effort to better specify the definition of 
> OPTIONS method, or if for them make more sense to leave 
> OPTIONS alone and create something new.
> 
> cheers
> Sal
> 
> 
> >> capabilities is pretty broken and then it is not useful to 
> provide a 
> >> meaningful service.
> >>
> >> capabilities, if Bob ha registered two or more UAs, then 
> the OPTIONS 
> >> request forks and arrive to all the registered UAs; 
> however the proxy 
> >> performing the forking forwards back to Alice only the 
> first response 
> >> it receives.
> >>      
> >> rather Alices device) know if Bob can take audio on one 
> device, but 
> >> video, video and text on his other visual friendly device.
> >>      
> > What would you do? Have the proxy send *new* OPTIONS to each 
> > registered device and then consolidate the results? Would 
> that entail 
> > a multipart/alternative containing SDP from each contact?
> >
> >    
> >> granularity, it helps Alice's device understand that while 
> on a voice 
> >> session with Bob, it is no way a re-INVITE to video would 
> work, but 
> >> instead her device should send a new video-session INVITE 
> towards Bob 
> >> allowing hi to press the 'yes' button on the visual device.
> >>      
> > Also, Alice then needs a way of directing the new INVITE to the 
> > intended destination. (Perhaps callerprefs would meet this need, 
> > perhaps not.)
> >
> >    
> >> Thus, there would be two parallel sessions between Alice 
> and Bob, one 
> >> for voice and the second one for video/text/picture.
> >> context for capabilities, where as Paul points out in his mail at 
> >> moment with the currents OPTIONS request capabilities are 
> context free.
> >>      
> >> The capabilities should not be considered stable over 
> time, however 
> >> they can be regarded as stable (but without any guarantees) if an 
> >> INVITE take places within short time.
> >> Thus, Alice wants to communicate with Bob "now" but first wants to 
> >> check "what" Bob can do. That is why she sends an OPTIONS. Soon as 
> >> she knows the capabilities, she immediately invokes a 
> compatible (to 
> >> the capabilities received) communication manner.
> >>      
> > call, or what it will be able to do once that call has ended? (Both 
> > may be useful pieces of information.)
> >
> > 	Thanks,
> > 	Paul
> >
> >    
> >> Cheers
> >> Sal
> >>
> >>
> >> Gonzalo Camarillo wrote:
> >>      
> >>> Hi Paul,
> >>>
> >>>
> >>>        
> >>>> The whole concept that OPTIONS will tell you the capabilities of 
> >>>> the UA is pretty broken - it assumes those are stable 
> over time and 
> >>>> are context free, which is often not the case. There are almost 
> >>>> never any guarantees that the info you receive from OPTIONS will 
> >>>> still be true if you try to act on it.
> >>>>
> >>>> The concept that the response code from OPTIONS should 
> be the same 
> >>>> as you would get were you to send an INVITE is even more 
> broken. It

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 21 Jan 2010 09:15:28 -0500

Christer,

I agree with you that there is need to specify the handling of specific 
headers, etc. in OPTIONS. But that ought to be consistent with a general 
philosophy of how OPTIONS is intended to work. It seems that philosophy 
is currently inadequate.

	Thanks,
	Paul