Subject: [sipcore] Draft new version: draft-ietf-sipcore-info-events-05

From: Christer Holmberg <[email-masked]>
Date: Mon, 18 Jan 2010 07:56:54 +0100

Hi,

Based on the WGLC comments, a new version (-05) of the info-event draft has been submitted.

It can also be found at:

http://users.piuha.net/cholmber/drafts/draft-ietf-sipcore-info-events-05.txt

Since there has been some e-mail editing etc, please take a look and make sure that your comments/issues have been addressed.

Regards,

Christer

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 18 Jan 2010 09:43:36 +0100

Looks good to me.

John

________________________________
From: Christer Holmberg [mailto:[email-masked]]
Sent: 18 January 2010 06:57
To: SIPCORE
Cc: Adam Roach; Gonzalo Camarillo; Eric Burger; Hadriel Kaplan; Robert Sparks; Paul Kyzivat; Elwell, John
Subject: Draft new version: draft-ietf-sipcore-info-events-05

Hi,

It can also be found at:

Regards,

Christer

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 18 Jan 2010 15:38:13 +0200

Hi,

we need to make sure we get the expansion of Table 2 and the IANA stuff 
right. We need someone to look at Section 6.1 in detail and confirm that 
everything is correct. Also, we need someone to do the same with Section 11.

Thanks,

Gonzalo

Christer Holmberg wrote:
> _http://users.piuha.net/cholmber/drafts/draft-ietf-sipcore-info-events-05.txt_
>  
> Since there has been some e-mail editing etc, please take a look and 
> make sure that your comments/issues have been addressed.
>  
> Regards,
>  
> Christer
>  
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 18 Jan 2010 15:40:43 +0200

Hi,

[sorry for splitting this note into two messages, the previous one and 
this one]

another point that has been much discussed in the past has been the ABNF 
syntax. If someone could do a similar review of Section 8.2, that would 
be appreciated.

Thanks,

Gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 19 Jan 2010 09:23:16 -0500

> syntax. If someone could do a similar review of Section 8.2, that would 

I commented already, and those comments were dealt with.
I've just now looked again more carefully, and the ABNF looks ok to me.

	Paul

> Thanks,
> 
> Gonzalo
> 
> Gonzalo Camarillo wrote:
>> Hi,
>>
>> we need to make sure we get the expansion of Table 2 and the IANA 
>> stuff right. We need someone to look at Section 6.1 in detail and 
>> confirm that everything is correct. Also, we need someone to do the 
>> same with Section 11.
>>
>> Thanks,
>>
>> Gonzalo
>>
>>
>> Christer Holmberg wrote:
>>>  
>>> Hi,
>>>

---

From: Robert Sparks <[email-masked]>
Date: Tue, 19 Jan 2010 15:35:32 -0600

I would also have removed
" The reviewer does not consider the applicability of the Info Package  
The reviewer does not consider the applicability of the Info Package  
for the usage for which it is defined."

RjS

---

From: Dean Willis <[email-masked]>
Date: Tue, 19 Jan 2010 23:59:59 -0600

On Jan 19, 2010, at 3:35 PM, Robert Sparks wrote:

> " The reviewer does not consider the applicability of the Info  
> Package The reviewer does not consider the applicability of the Info  
> Package for the usage for which it is defined."

While the language is broken, the intent is that the reviewer not say  
"This is a silly thing to do with an INFO package. Why, we should be  
doing this with SOAP (or insert your favorite modality) instead."  As  
a group, we tend to review SIP extensions through something of a  
religious lens, to say "But that usage isn't the intent of SIP; SIP is  
only for (insert favorite thing here)!"

The goals of an INFO package reviewer should be to be to 1) verify  
that the document exists and actually specifies an INFO package, not  
something completely different (like say, a recipe for cheese dip), 2)  
verify that the INFO package name is unique, and 3) confirm that the  
INFO package is not trying to sneak modifications of the SIP State  
machine into the specification family; there MUST be no normative  
language that alters the SIP state machine functionality.

If somebody wants "INFO for lightbulbs", that's OK. If they want "INFO  
for remote procedure calls", that's OK too. Neither may be a  
particularly smart usage of SIP, but they don't break the SIP  
protocol, and that's all the reviewer should care about.

--
Dean

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 20 Jan 2010 07:38:42 +0100

Hi Dean,

So, you want to keep the text?

Regards,

Christer 

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]] 
> Sent: 20. tammikuuta 2010 8:00
> To: Robert Sparks
> Cc: Christer Holmberg; SIPCORE; Gonzalo Camarillo; Hadriel Kaplan
> Subject: Re: [sipcore] Draft new version: 
> draft-ietf-sipcore-info-events-05
> 
> 
> While the language is broken, the intent is that the reviewer 
> not say "This is a silly thing to do with an INFO package. 
> Why, we should be doing this with SOAP (or insert your 
> favorite modality) instead."  As a group, we tend to review 
> SIP extensions through something of a religious lens, to say 
> "But that usage isn't the intent of SIP; SIP is only for 
> (insert favorite thing here)!"
> 
> The goals of an INFO package reviewer should be to be to 1) 
> verify that the document exists and actually specifies an 
> INFO package, not something completely different (like say, a 
> recipe for cheese dip), 2) verify that the INFO package name 
> is unique, and 3) confirm that the INFO package is not trying 
> to sneak modifications of the SIP State machine into the 
> specification family; there MUST be no normative language 
> that alters the SIP state machine functionality.
> 
> 
> If somebody wants "INFO for lightbulbs", that's OK. If they 
> want "INFO for remote procedure calls", that's OK too. 
> Neither may be a particularly smart usage of SIP, but they 
> don't break the SIP protocol, and that's all the reviewer 
> should care about.
> 
> --
> Dean
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 20 Jan 2010 07:39:43 +0100

Hi,

A possible comprimise would be to keep the text, but make it into a note.

Regards,

Christer 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Christer Holmberg
> Sent: 20. tammikuuta 2010 8:39
> To: Dean Willis; Robert Sparks
> Cc: SIPCORE; Gonzalo Camarillo; Hadriel Kaplan
> > "This is a silly thing to do with an INFO package.
> > Why, we should be doing this with SOAP (or insert your favorite 
> > modality) instead."  As a group, we tend to review SIP extensions 
> > through something of a religious lens, to say "But that usage isn't 
> > the intent of SIP; SIP is only for (insert favorite thing here)!"
> > 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 19 Jan 2010 23:21:43 +0100

Hi,

>" The reviewer does not consider the applicability of the Info Package The reviewer does not consider the >applicability of the Info Package for the usage for which it is defined."

That's a misstake. The intention was to remove it. I'll fix it.

Thanks!

Christer

---

From: Robert Sparks <[email-masked]>
Date: Wed, 20 Jan 2010 00:56:29 -0600

I don't think we need to keep the text - that's already what  
Specification Required says.

RjS

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 20 Jan 2010 18:50:27 +0100

Hi,

Earlier we had a rather lenghty discussion about this, I believe all text was presented on the list before added to the draft, and nobody objected...

Anyway, does anyone object if I now remove the text?

Regards,

Christer

________________________________________
From: Robert Sparks [[email-masked]]
Sent: Wednesday, January 20, 2010 8:56 AM
To: Christer Holmberg
Cc: Dean Willis; SIPCORE; Gonzalo Camarillo; Hadriel Kaplan
Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-info-events-05

RjS

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 21 Jan 2010 02:07:19 +0100

+1 to Dean's comments.

I would also add that this issue got extensive discussion on the list when these words were inserted.

regards

Keith 

> [mailto:[email-masked]] On Behalf Of Dean Willis
> Sent: Wednesday, January 20, 2010 6:00 AM
> To: Robert Sparks

---

From: Dean Willis <[email-masked]>
Date: Wed, 20 Jan 2010 22:37:04 -0600

> So, you want to keep the text?

Well, I suspect that the text could be better worded, perhaps even  
written in proper English. But I think I agree with the intent.

--
dean

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 21 Jan 2010 07:48:17 +0100

Hi,

>Well, I suspect that the text could be better worded, perhaps 
>even written in proper English. But I think I agree with the intent.

Feel free to propose some properly written text :)

Regards,

Christer

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 21 Jan 2010 12:47:12 +0100

I do not want to remove the text - and Dean has explained exactly why in better words than I can.

I am happy to look at rewordings, but we have had too many instances where expert review has gone into considerable detail, and that we have consensus on is not meant here.

Keith 

> Sent: Wednesday, January 20, 2010 5:50 PM
> To: Robert Sparks
> Earlier we had a rather lenghty discussion about this, I 
> believe all text was presented on the list before added to 
> the draft, and nobody objected...
> 
> >>> If somebody wants "INFO for lightbulbs", that's OK. If they want 
> >>> "INFO for remote procedure calls", that's OK too.
> >>> Neither may be a particularly smart usage of SIP, but they don't 
> >>> break the SIP protocol, and that's all the reviewer should care 
> >>> about.
> >>>
> >>> --
> >>> Dean
> >>>

---

From: Robert Sparks <[email-masked]>
Date: Thu, 21 Jan 2010 09:27:39 -0600

I think what its trying to say is exactly what 5226 says in its  
definition of
Specification Required and that we run the risk of introducing ambiguity
and confusion by trying to duplicate what's said there.

I don't think we're trying to modify that definition and that the  
pressure
you're trying to put on it would be clarifying pressure. There might be
better text that could do that without introducing ambiguity, but we've
noted the current text isn't it. My proposed alternate text is the  
empty string.

If we _are_ trying to modify that definition, then we need quite a bit
of different, and very explicit, text.

RjS

On Jan 21, 2010, at 5:47 AM, DRAGE, Keith (Keith) wrote:

> I am happy to look at rewordings, but we have had too many instances  
> where expert review has gone into considerable detail, and that we  
> have consensus on is not meant here.
>
> Keith
>

---

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

We can always say "according to RFC 5226, blah blah blah".

The -v5 text says:
==================

"The registration policy for the registry is Specification Required
[RFC5226].

In any case, if we go forward with this, it needs to be modified, because now "reviewer" seems to come out of the blue.

The -v4 text says:
==================

"Based on [RFC5226], IANA assigns an expert in order to review an Info
Package which is to be registered. The Info Package specification is
provided to the reviewer, who ensures that the Info Package is
described in a proper way.

In any case, if we go forward with this, it needs to be modified, because I think "Specification Required" should be mentioned.

Now, a compromise could be:
===========================

"The registration policy for the registry is Specification Required [RFC5226].

According to [RFC5226], IANA assigns an expert in order to review an Info Package 
which is to be registered. The reviewer ensures that the Info Package is defined 
in a proper way, but does not consider the applicability of the usage for which 
the Info Package is defined."

Regards,

Christer

> From: Robert Sparks [mailto:[email-masked]] 
> Sent: 21. tammikuuta 2010 17:28
> To: DRAGE, Keith (Keith)
> I think what its trying to say is exactly what 5226 says in 
> its definition of Specification Required and that we run the 
> risk of introducing ambiguity and confusion by trying to 
> duplicate what's said there.
> 
> I don't think we're trying to modify that definition and that 
> the pressure you're trying to put on it would be clarifying 
> pressure. There might be better text that could do that 
> without introducing ambiguity, but we've noted the current 
> text isn't it. My proposed alternate text is the empty string.
> 
> If we _are_ trying to modify that definition, then we need 
> quite a bit of different, and very explicit, text.
> 
> RjS
> 
> > I do not want to remove the text - and Dean has explained 
> exactly why 
> > in better words than I can.
> >
> believe all 
> >> text was presented on the list before added to the draft, 
> and nobody 
> >> objected...
> >>
> >>> A possible comprimise would be to keep the text, but make 
> it into a 
> >>> note.
> >>>
> >>> Regards,
> >>>
> >>> Christer
> >>>

---

From: Dean Willis <[email-masked]>
Date: Fri, 22 Jan 2010 09:55:01 -0600

> of different, and very explicit, text.

5226 says:

"Specification Required - Values and their meanings must be documented  
in a permanent and readily available public specification, in  
sufficient detail so that interoperability between independent  
implementations is possible. When used, Specification Required also  
implies use of a Designated Expert, who will review the public  
specification and evaluate whether it is sufficiently clear to allow  
interoperable implementations. The intention behind "permanent and  
readily available" is that a document can reasonably be expected to be  
findable and retrievable long after IANA assignment of the requested  
value. Publication of an RFC is an ideal means of achieving this  
requirement, but Specification Required is intended to also cover the  
case of a document published outside of the RFC path. For RFC  
publication, the normal RFC review process is expected to provide the  
necessary review for interoperability, though the Designated Expert  
may be a particularly well-qualified person to perform such a review."

The problem the text was trying to resolve is that we (the SIP  
community in IETF) have a strong history of being fussy about SIP  
extensions. We don't really know how to live within the implications  
of "Specification Required" and were trying to leave ourselves a note  
reminding us how to do our jobs, so that when it comes up (and it  
well) the argumentation is there to fall back on. But there is a  
certain critical element of "fussiness" that we wish to preserve; the  
INFO package being defined MAY be silly, but it MUST NOT functionally  
change the SIP protocol or state machine. INFO is a pure-and-simple  
use of SIP for transport, and just as we wouldn't define an HTTP  
extension that says "If the result of the GET is a MIME object of type  
foo/bar, then the browser MUST terminate immediately without properly  
closing the TCP connection", we wouldn't do something equally  
destructive to SIP in an INFO package (although I'm not sure we won't  
do something that crazy on the standards track!).

Let me propose some alternate text:

Note to Reviewers

The policy for review of INFO packages is "Specification Required" as  
in RFC 5226. This policy was selected because INFO packages re-use an  
existing  mechanism for transport of arbitrary session-associated data  
within SIP, and therefore new INFO packages do not require the more  
extensive review required by specifications that make fundamental  
protocol changes. However, the reviewer is expected to verify that  
each INFO package registration is in fact consistent with this  
definition. Changes to the SIP protocol and state machine are outside  
of the allowable scope for an INFO package and are governed by other  
procedures including RFC 3427 and its successors, if any.

--
Dean

---

From: Robert Sparks <[email-masked]>
Date: Fri, 22 Jan 2010 13:24:33 -0500

I'd be ok with that text.

Just to make sure we're explicit, do you think this absolves the  
reviewer of making sure the
specification meets the requirements that this new RFC would put on  
any new package?
We had a long conversation essentially about whether a blank, but  
stable, document satisfied
specification required. I want to make sure we don't regress and lose  
where that conversation
ended.

RjS

On Jan 22, 2010, at 10:55 AM, Dean Willis wrote:

> "Specification Required - Values and their meanings must be  
> documented in a permanent and readily available public  
> specification, in sufficient detail so that interoperability between  
> independent implementations is possible. When used, Specification  
> Required also implies use of a Designated Expert, who will review  
> the public specification and evaluate whether it is sufficiently  
> clear to allow interoperable implementations. The intention behind  
> "permanent and readily available" is that a document can reasonably  
> be expected to be findable and retrievable long after IANA  
> assignment of the requested value. Publication of an RFC is an ideal  
> means of achieving this requirement, but Specification Required is  
> intended to also cover the case of a document published outside of  
> the RFC path. For RFC publication, the normal RFC review process is  
> expected to provide the necessary review for interoperability,  
> though the Designated Expert may be a particularly well-qualified  
> person to perform such a review."
>
> of "Specification Required" and were trying to leave ourselves a  
> note reminding us how to do our jobs, so that when it comes up (and  
> it well) the argumentation is there to fall back on. But there is a  
> certain critical element of "fussiness" that we wish to preserve;  
> the INFO package being defined MAY be silly, but it MUST NOT  
> functionally change the SIP protocol or state machine. INFO is a  
> pure-and-simple use of SIP for transport, and just as we wouldn't  
> define an HTTP extension that says "If the result of the GET is a  
> MIME object of type foo/bar, then the browser MUST terminate  
> immediately without properly closing the TCP connection", we  
> wouldn't do something equally destructive to SIP in an INFO package  
> (although I'm not sure we won't do something that crazy on the  
> standards track!).
>
> The policy for review of INFO packages is "Specification Required"  
> as in RFC 5226. This policy was selected because INFO packages re- 
> use an existing  mechanism for transport of arbitrary session- 
> associated data within SIP, and therefore new INFO packages do not  
> require the more extensive review required by specifications that  
> make fundamental protocol changes. However, the reviewer is expected  
> to verify that each INFO package registration is in fact consistent  
> with this definition. Changes to the SIP protocol and state machine  
> are outside of the allowable scope for an INFO package and are  
> governed by other procedures including RFC 3427 and its successors,  
> if any.
>
>
> --
> Dean

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sat, 23 Jan 2010 00:16:24 +0100

Would you like to clarify exactly how tou get your interpretation from the RFC 5226 text.

For example the bits about interoperability certainly imply to me that the expert has to a much more extensive review than what was intended.

In other words, act as the expert would when presented with an info package definition, and tell me what you would look at using the RFC 5226 definition, what tests you would apply and so on.

regards

Keith 

> Sent: Thursday, January 21, 2010 3:28 PM
> To: DRAGE, Keith (Keith)

---

From: Dean Willis <[email-masked]>
Date: Fri, 22 Jan 2010 22:46:03 -0600

On Jan 22, 2010, at 12:24 PM, Robert Sparks wrote:

> specification required. I want to make sure we don't regress and  
> lose where that conversation
> ended.

I'd say that the reviewer should look at the specification and at  
least see that it is attempting to specify an INFO package. This is  
arguably slightly below the bar set by 5226, which I think requires a  
reviewer to decide that the specification is good enough that it could  
be implemented with some hope of interoperability. I'm still pondering  
whether we should have just said "first come first served".

  I'd be willing to accept even the "bar set by 5226", as long as the  
reviewer does not get to determine whether the INFO package is  
specifying "something that is reasonable to do with SIP". I don't care  
whether the intent is "reasonable" or not; if there's a legible  
specification, we register the info package. If somebody really wants  
to reimplement BitTorrent in INFO and publishes a spec that shows how  
to do it, we register that INFO package without complaint about it  
being a really stupid thing to do with SIP. We need to get out of the  
position of being the stupidity police for the users of our protocol.  
If they want to shoot themselves, so be it; we're here to keep them  
from shooting each other accidentally by using the same package name.

--
Dean

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 25 Jan 2010 11:44:42 +0100

Hi,

Could you please show how the whole section would look like?

Thanks!

Christer 

> Sent: 23. tammikuuta 2010 6:46
> To: Robert Sparks
> > reviewer of making sure the specification meets the 
> requirements that 
> > this new RFC would put on any new package?
> > stable, document satisfied specification required. I want 
> to make sure 
> > we don't regress and lose where that conversation ended.
> 
> I'd say that the reviewer should look at the specification 
> and at least see that it is attempting to specify an INFO 
> package. This is arguably slightly below the bar set by 5226, 
> which I think requires a reviewer to decide that the 
> specification is good enough that it could be implemented 
> with some hope of interoperability. I'm still pondering 
>   I'd be willing to accept even the "bar set by 5226", as 
> long as the reviewer does not get to determine whether the 
> INFO package is specifying "something that is reasonable to 
> do with SIP". I don't care whether the intent is "reasonable" 
> or not; if there's a legible specification, we register the 
> info package. If somebody really wants to reimplement 
> BitTorrent in INFO and publishes a spec that shows how to do 
> it, we register that INFO package without complaint about it 
> being a really stupid thing to do with SIP. We need to get 
> out of the position of being the stupidity police for the 
> users of our protocol.  
> If they want to shoot themselves, so be it; we're here to 
> keep them from shooting each other accidentally by using the 
> same package name.
> 
> --
> Dean

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 26 Jan 2010 09:50:34 +0100

Are people ok with the following text?

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

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

   Note to Reviewers:

   The policy for review of Info Packages is "Specification Required", as
   defined in [RFC5226]. This policy was selected because INFO packages re-use 
   an existing mechanism for transport of arbitrary session- associated 
   data within SIP, and therefore new INFO packages do not require the 
   more extensive review required by specifications that make fundamental 
   protocol changes. However, the reviewer is expected to verify that 
   each INFO package registration is in fact consistent with this 
   definition. Changes to the SIP protocol and state machine are outside 
   of the allowable scope for an INFO package and are governed by other  
   procedures including [RFC3427] and its successors, if any.

   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

> Sent: 25. tammikuuta 2010 12:45
> long as the 
> > whether the intent is "reasonable"
> > or not; if there's a legible specification, we register the info 
> > package. If somebody really wants to reimplement BitTorrent in INFO 
> > and publishes a spec that shows how to do it, we register that INFO 
> > package without complaint about it being a really stupid 
> thing to do 
> > with SIP. We need to get out of the position of being the stupidity 
> > police for the users of our protocol.

---

From: Dean Willis <[email-masked]>
Date: Tue, 26 Jan 2010 12:02:30 -0600

> Are people ok with the following text?

Works for me.

--
Dean

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 27 Jan 2010 09:00:52 +0100

Hi,

Ok, I will submit a new version later today. It will also contain some spelling error corrections that I have been informed about, but otherwise there will be no other changes.

Regards,

Christer 

> Sent: 26. tammikuuta 2010 20:03
> To: Christer Holmberg
> Cc: Robert Sparks; SIPCORE; Gonzalo Camarillo; Hadriel Kaplan

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 27 Jan 2010 10:16:08 +0200

Hi Christer,

please, make sure the ID nits tool does not complain about the new
version... the idea is to be able to request its publication.

Thanks,

Gonzalo