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

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 12 Oct 2009 18:53:43 +0300

Folks,

the authors have submitted a new revision of this draft, which addresses 
the WGLC comments they received. Please, have a look at it since we 
intend to request its publication shortly.

Thanks,

Gonzalo
SIPCORE co-chair

Christer Holmberg wrote:
> 
> INFO lovers, INFO haters, and those who couldn't care less,
> 
> Based on the earlier comments, WGLC comments, and the recent 
> discussions, we've put together a new version of the info events draft.
> 
> The comments we have got indicated confusion and inconsistancy about the 
> terminology used (UAC/UAC, negotiation etc etc etc). We've really worked 
> hard trying to fix that in the new version. However, that has meant 
> quite big editorial changes in some places, so I really request people 
> that have provided comments on earlier versions (and maybe even got 
> their comments implemented later) to take a look and make sure they are 
> ok with the text.
> 
> You can also get the draft from:
> 
> _http://users.piuha.net/cholmber/drafts/draft-ietf-sipcore-info-events-01.txt_ 
> 
> 
> Regards,
> 
> Christer
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 13 Oct 2009 16:18:20 +0300

Folks,

given that the changes from 00 to 01 have been quite extensive, we have 
decided to issue a new WGLC on this draft. This WGLC will end on October 
27th. Please, send your comments to this list.

Thanks,

Gonzalo
SIPCORE co-chair

Gonzalo Camarillo wrote:
>> The comments we have got indicated confusion and inconsistancy about 
>> the terminology used (UAC/UAC, negotiation etc etc etc). We've really 
>> worked hard trying to fix that in the new version. However, that has 
>> meant quite big editorial changes in some places, so I really request 
>> people that have provided comments on earlier versions (and maybe even 
>> got their comments implemented later) to take a look and make sure 
>> they are ok with the text.
>>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Robert Sparks <[email-masked]>
Date: Wed, 14 Oct 2009 13:37:07 -0500

In fact, many of the sections are complete rewrites, and it has helped  
the draft. Please take some time to review it.

RjS

On Oct 13, 2009, at 8:18 AM, Gonzalo Camarillo wrote:

> Folks,
>
> given that the changes from 00 to 01 have been quite extensive, we  
> have decided to issue a new WGLC on this draft. This WGLC will end  
> on October 27th. Please, send your comments to this list.
>
> Thanks,
>
> Gonzalo
> SIPCORE co-chair
>
> Gonzalo Camarillo wrote:
>> Folks,
>> the authors have submitted a new revision of this draft, which  
>> addresses the WGLC comments they received. Please, have a look at  
>> it since we intend to request its publication shortly.
>> Thanks,
>> Gonzalo
>> SIPCORE co-chair
>> Christer Holmberg wrote:
>>>
>>> The comments we have got indicated confusion and inconsistancy  
>>> about the terminology used (UAC/UAC, negotiation etc etc etc).  
>>> We've really worked hard trying to fix that in the new version.  
>>> However, that has meant quite big editorial changes in some  
>>> places, so I really request people that have provided comments on  
>>> earlier versions (and maybe even got their comments implemented  
>>> later) to take a look and make sure they are ok with the text.
>>>

---

From: Robert Sparks <[email-masked]>
Date: Wed, 14 Oct 2009 15:52:05 -0500

Just as a point of convenience, it would really help, days or maybe  
months from now, to have the string WGLC in the subject line for  
things like this.

RjS

---

From: Robert Sparks <[email-masked]>
Date: Wed, 14 Oct 2009 15:55:31 -0500

First, this version is a big improvement to the text. Christer put in
a great deal of thought and effort resulting in a really good job
rewriting several sections. Thanks!

I have a lot of comments below, but overall I think the document is
gettig much closer to done.

Here's my feedback (as an individual) on -01:

Major

This is my biggest comment for this version and I'm taking it out of
order to call attention to it. I think we've got some confusion in
the IANA considerations section that we need to talk through. The
document is setting up a First-Come-First-Served registry using
"Specification Required" (which means that document has to exist
somewhere, but not necessarily one that's been "approved" by any
standards body), but we're calling such things "Standards Track" in
the registration. What is it that we're really trying to set up?
Whatever it is, please align it with 3427bis.

(If the current text survives, we'll need to be very explicit with
what "modified" means before this gets to IANA).

When thinking about this, we need to make sure section 7.11 is
aligned to the conclusion.  Specifically, is it ok to have a package
registered that points to a company or individual's website for the
application procedures?

I spotted two things to call attention to that _aren't_ in the draft.

One thing that didn't survive the rewrite that I think we should work
back in is a note to implementors that an INFO might arrive from a
peer even before the first end-to-end provisional (because it might
win a race with an immediate 200 OK) and this is not an error.

The edit also addressed my concern about calling out to the obsoleted
INFO document for definition of behavor by leaving removing any
references of a normative nature. I think the current approach will
probably work, but I'm still thinking it through and encourage review
from this point of view from others.

The rest of these are in document order.

I would like 3.4 (which requires putting Recv-Info into REGISTER
requests) to be deleted. I don't believe there is sufficient
motivation to include this requirement and there is certainly
insufficient specification of what it would mean for it to be there
for it to be useful. If some future package or usage really wants to
affect rendezvous this way, then let it specify it. Requiring that
extra bits be pumped around the network because something _might_
want to use it is not the right thing to do.

Similarly, it seems very strange to both require that elements
put information into an OPTIONS request and then require other
elements to ignore it (Section 3.5). What good is going to come
from putting these bits in the OPTIONS request?

The structure of section 4.4 is a little off. It would help the logic
flow to move the meaning of the last paragraph to the first of the
section. Words like "Normal processing as required by [RFC3261] might
require a failure response to be sent to the INFO request. If no such
requirement constrains the UA, then..."

I still have not reviewed the tables in 5.1 and 5.2.
Please make sure someone is on record as having done so before
this is pub-requested. That said, I noticed based on looking
at the diffs that "o"'s have been added for NOT and RFR. Why?
(and if it makes sense for them to be there, why didn't they
also end up in SUB?). Btw - thanks for working with my
suggestion leading to the m* under INF.

Section 7.1 last paragraph. I think we should ask any future
packages to explicitly explain when one of the issues section
7 calls out is not applicable. I suggest replacing "unless an
issue is not applicable" with "or document why an issue is not
applicable".

Section 7.7 last paragraph: This MUST NOT requirement makes
no sense, _especially_ for the specific case the paragraph
calls out. What is the paragraph trying to accomplish?

Section 8.2 ABNF: We've struggled before with the addition
of new header fields to the ABNF. Trying to use / as the
document currently does for extension-method does the wrong thing.
I suggest we follow the approach the outbound draft took instead.
Has anybody run the ABNF in this section through an automated
checker?

Section 11 should be titled "Security Considerations".  I suggest
Section 7.10 be relabelled "Info Package Security Considerations".
The first sentence from Section 11 (quoted below) is at odds with the
proposed First-come-first-served registration:
"By eliminating multiple uses of INFO messages without adequate
community review and by eliminating the possibility for rogue SIP UAs
from confusing another User Agent by purposely sending unrelated INFO
requests, we expect this document's clarification of the use of INFO
to improve the security of the Internet."

Why is Appendix A an appendix? I suspect that's editing legacy.
Unless there's a compeling reason to leave it as an appendix, please
move it into the main body of the document.
(B and C are ok as Appendices)

Minor

There are still several instances of using 2119 words to constrain
other documents or standards work rather than constraining protocol.
There should be no 2119 words, for instance, in section 4.6.
The MUST NOT in section 7.12 is another strong example.

Page 5 second to last pararaph last sentence: I don't think
"identical" is the word you want to use here. I suggest "analogous"
instead.

Page 9, ACK message:
  * The branch parameter must be different in an ACK to a 200
  * The message needs a Max-Forwards
  * The CSeq doesn't match the INVITE/200.

Page 10, section 4.1 Second paragraph:
This wording is confusing. It essentially says "New things follow
this specification and old things don't. New things should be
prepared to act like old things when old things talk to them". This
backwards-compatibility requirement is adequately captured elsewhere,
I suggest deleting the paragraph.

Page 10, section 4.2 3rd paragraph:
Suggest adding "beyond its transaction" after "has no lifetime"

Page 11, section 4.3, 6th paragraph:
Suggest adding "even" as follows: "In that case, even if multipart
MIME is used,"

Page 12 second paragraph: Suggest adding a forward reference to the
section defining the 469 response code here where the code is first
mentioned.

Page 12 section 4.5 : "is normally generated by the SIP stack" goes
too far. Similarly the MUST requirement in the 2nd paragraph (sending
a INFO) not really the constraint we need. I suggest replacing the
section with this text:
  "The Info Package Framework is designed to allow a SIP stack to
generate a response to an INFO message without application
interaction. As a result, Info Packages cannot require bodies in INFO
responses, require different response codes, or otherwise require
application information be placed in the response to the INFO
request. If the application has information to send in the other
direction, one alternative available to it is sending a new INFO
request."

The first paragraph on page 16, last sentence says a request without
an Info-Package header MUST NOT contain an Info-Package header :).
(What did it really mean to say?)

Page 17, Section 7.3: Why is there a requirement for a name here
that's separate from the header field value?

Page 17 Section 7.4 second paragraph: This could be read to say two
packages cant share the same parameter name. Can we rewrite it to
avoid that misinterpretation?

Why hasn't the changelog been kept up? There are at least
two revisions worth of changes (the most recent will probably
be pretty hard to write). The working group will need to
decide whether to bring it up to date, delete the section
before requesting IETF-wide review, or add a section explaining
the gap in information before we proceed.

Nits:

Page 5 second to last paragraph: missing an "of" between "big risk"
and "interoperability"?

Page 6 3rd paragraph, first sentence should have its commas moved
around or be rephrased. Suggest "If a UA supports the Info Package
mechanism, it uses the Recv-Info header field, on a per-session
bases, to indicate which Info Packages it is willing to receive."

Page 8 4th paragraph: wit->with

Page 10 1st paragraph: Suggest deleting the first occurance of the
word "how".

Page 10 section 4.2 3rd paragraph: The document should use a
consistent human-readable phrase for 481 throughout.

Page 11 section 4.3 3rd paragraph: "filed" -> "field"

Page 12 section 4.4 3rd paragraph: Is this "must" supposed to be
"MUST"?

Page 15 section 6 1st paragraph 1st sentence: "the and a"? Is this
really two sentences that need to be teased back apart?

Page 15 section 6 2nd paragraph "to not" -> "do not"

Page 17 section 7.3 : what should "**9" be?

Page 17, section 7.5 : please poing to 3492bis instead.

Page 18, section 7.8 first paragraph: Missing "define" after MUST.
   (and this shouldn't be a 2119 word).

Page 19 paragraph at the top of the page: Suggest replacing
"The most common method" with "One way".

Page 19 end of sedction 8.2 (A very little pedantic nit):
Suggest saying "more than one Recv-Info header field name."

Appendix C : Out of curiosity, which are the four paragraphs
from the Litmus draft? Are they still here and intact?

Appendix C : I think we should delete the "My, we have been"
sentence.

Appendix C : The number of messages stats are impressive, but
completely useless to the reader of an RFC once it's published.
I suggest we move that information out of the draft, into the
tracker in the "protocol quality" field of the writeup.

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 15 Oct 2009 22:46:47 +0200

I appreciate this document has undergone a significant rewrite, but unfortunately this seems to have introduced a bunch more errors. Perhaps I didn't read the previous version carefully enough. Below are my main comments. There are lots of nits, which I will send to Christer separately.

1. I think the document would benefit from having a definition of Info Package at some point early on. In section 1 we have "This document defines a mechanism, using Info Packages, which
   provides the possibility for UAs to indicate what INFO usages they
   support, and to define content syntax and semantics for the data
   transported in the INFO messages.",
but that describes the mechanism, rather than defining Info package. As a starter, how about something like:
"A specified usage of the SIP INFO method, detailing the format and semantics of information transported."

2. In several places in the document (e.g., Abstract, section 1), it talks about receiving Info Packages, but I think that is incorrect. Shouldn't it really be worded along the lines of receiving information within the context of an Info Package? (c.f., RFC 3265, where we don't receive event packages in NOTIFY requests, we receive events).

3. Was there a reason why we decided to use "Recv-Info: nil" rather than simply "Recv-Info:" if not willing to receive?

4. Although much of the document talks about INFO within the context of an invite dialog usage, there are many places that mention session, which seems inconsistent. Session is used early in section 1, but that is probably reasonable, as it describes the basic capability of SIP. However, later we have
"INFO messages are always part of, and share the fate of, an invite
   dialog usage.  INFO message can not be sent as part of other dialog
   usages, and they can not be sent outside an existing session."
I cannot rationalise this mixture of invite dialog usage and session in the same sentence. In this particular case, I don't see what value "and they can not be sent outside an existing session" adds.
Then later:
"which Info Packages it is willing to receive,
   on a per-session basis"
and
"during the lifetime of the invite dialog usage of the
   session"
What is "dialog usage of the session"?
And so on. We should decide whether to talk about INFO being used in the context of a session or of an invite dialog usage and use that terminology consistently.

5. I think it has already been questioned why we use Recv-Info in a REGISTER request. Forking decisions are based on RFC 3840 UA capabilities, and if decisions need to be made based on Info Package support, we should extend that mechanism. Also, the semantics of Recv-Info are that it indicates packages it is willing to receive. The presence of a package in Recv-Info in an INVITE request does NOT convey any meaning about wanting to select a UAS that can receive that same package.

6. In the example in 3.6:
"Since the UAS does not support Info Package P, the UAC decides to
   indicate in the ACK request that it is only willing to receive Info
   Package R, which the UAS also indicated support of."
Whilst this is certainly legitimate behaviour (a UA can change its mind about what it wishes to receive at any time), isn't there a danger with this example of implying that a UA should limit what it is prepared to receive to what the peer UA has indicated it is willing to receive? I don't think this aspect of the example is particularly helpful.

7. In 4.2: "If a UA receives an INFO
   request outside an existing dialog, the UA MUST response with a 481
   Call Does Not Exist error response."
What if INFO request is received within the context of a dialog but a dialog for which there is no invite usage?
But I see that is covered in 4.4. Shouldn't both conditions be covered in 4.4, rather than one in 4.2 and the other in 4.4?

8. In 4.3: "The application data associated with an
   Info Package SHOULD be carried as a payload in the message body of
   the INFO request, unless the information can be retrieved from a SIP
   header field."
I don't remember discussing this exception. What sort of thing do we have in mind?

9. In 4.3 "In that case, if
   multipart MIME is used, the UA does not need to insert an 'Info-
   Package' header value for the individual body parts."
Does this mean it doesn't need to have a Content-Disposition header field associated with individual body parts?

10. In 4.4 "If a UA receives an INFO request, that carries a message body that
   the UA does not support, and support of the message body is required
   in the Content-Disposition header field, the UA MUST send a 415
   Unsupported Media Type response.  If support of the message body is
   optional, the UA MUST send a 200 OK response even if the UA does not
   support the message body."
I am confused. In 4.3 it says that Content-Disposition has the value "Info-Package", so how can it indicate support required/not required?
In addition, this paragraph should cover body parts, not just bodies.

11. In 5.2, why is Recv-Info allowed in NOTIFY request/response and in REFER request? These doesn't related to invite dialog usages.

12. In 5.2.2 "This document adds Recv-Info to the definition of the element
   "general-header" in the SIP [RFC3261] message grammar"
I can't find "general-header" in RFC 3261.

13. In section 6 "An INFO request associated with an Info Package MUST contain a Info-
   Package header field."
Since section 6 deals with "Legacy INFO Usage", this is not the place to make a normative statement concerning Info Packages. Instead it would be acceptable to mention what is mandated elsewhere (section 4).

14. In section 7.7 "If Info Package restrictions are violated (i.e. if overlapping INFO
   requests are not allowed for an Info Package, but a UA still receives
   overlapping requests), the UA MUST NOT reject such requests. "
This is in the section on Info Package Usage Restrictions. Such a normative statement on UA behaviour should occur in section 4. It can then be mentioned (informatively) in 7.7.

15. "5.2.2.  Recv-Info header field"
This occurs within section 5 "Formal INFO method definition", but has nothing to do with the INFO method.
Furthermore, I am not keen on the separation between the method and header field descriptions in 5 and the ABNF for these in section 8. Maybe 8 could be moved to directly after 5.

16. In 9.5: "Please add the following registration to the Content-Disposition
   registry.  The description suitable for the IANA registry is as
   follows.
   The payload of the message carrying this Content-Disposition header
   field value is the payload of an Info Package"
This text fails to state the value that is being registered.

17. Section 10 gives examples of the INFO method, whereas section 3.6 gives an example of the Recv-Info header field. It would make sense either to have all examples in one place or to have all examples in the sections to which they relate.

18. "11.  Modifications to SIP Change Process"
This is a strange title. The contents look like they constitute a Security Considerations section.

19. In B.2: "QSIG uses Content-Type to identify QSIG protocol elements in an INFO
   message.  See RFC4497 [RFC4497]."
 I am sure I made this comment before. RFC 4497 does NOT cover the conveyance of QSIG in INFO (it covers interworking between SIP and QSIG). The conveyance of QSIG in INFO is covered by Standard ECMA-355 (the IETF never adopted this work).

20. In 4.1 "It also
   describes how an UA can indicate support of Info Packages in OPTIONS
   requests and during registration."
Wasn't this already described in section 3?

John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Gonzalo Camarillo
> Sent: 13 October 2009 14:18
> To: SIPCORE
> Subject: Re: [sipcore] Draft new version: 
> draft-ietf-sipcore-info-events-01
> 
> Folks,
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 16 Oct 2009 23:14:30 +0200

Hi,

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

>requests) to be deleted. I don't believe there is sufficient motivation to include this requirement and >there is certainly insufficient specification of what it would mean for it to be there for it to be useful. >If some future package or usage really wants to affect rendezvous this way, then let it specify it. >Requiring that extra bits be pumped around the network because something _might_ want to use it is not the >right thing to do.

I am not sure I agree this would be package specific. I think that, for all packages, it could be useful to be able to do forking based this. Otherwise operators may have to rely on static configuration in the network, which I thought is something we want to avoid.

One of the biggest problem I hear about from the market is related to not being able to design reliable, consistent and effective forking algorithms, since some clients indicate some capabilities in registrations, other clients indicate some other capabilities in registrations, and some clients don't indicate anything.

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

>Similarly, it seems very strange to both require that elements put information into an OPTIONS request and 
>then require other elements to ignore it (Section 3.5). What good is going to come from putting these bits 
>in the OPTIONS request?

I don’t think the text talks about “ignoring”.

OPTIONS is used to query capabilities/extensions, but when sessions are established all capabilities/extensions etc must still be negotiated/required for each specific session. That is normal SIp procedures, and Info Packages are no different from any other capability/extension in that sense.

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

Regards,

Christer

---

From: Adam Roach <[email-masked]>
Date: Fri, 16 Oct 2009 16:54:00 -0500

On 10/16/09 4:14 PM, Christer Holmberg wrote:
>> requests) to be deleted. I don't believe there is sufficient motivation to include this requirement and>there is certainly insufficient specification of what it would mean for it to be there for it to be useful.>If some future package or usage really wants to affect rendezvous this way, then let it specify it.>Requiring that extra bits be pumped around the network because something _might_ want to use it is not the>right thing to do.
>>      

That was the reasoning for SUBSCRIBE and NOTIFY, from which this 
behavior has been borrowed. However, I don't think the situations are 
particularly comparable.

With SUBSCRIBE, the rationale was: if an endpoint registered with 
support for an event package, then a proxy could preferentially select 
it during target processing when a SUBSCRIBE came in for the associated 
event package. This is pretty watertight, because anything that doesn't 
support the event package is going to be completely incapable of doing 
anything even remotely useful if the SUBSCRIBE gets routed to it.

INFO is radically different. You can't send INFO outside of a dialog -- 
so, by the time an INFO is on the wire, it's ultimate destination has 
already been written in stone. The corresponding INVITE is very 
different than the SUBSCRIBE case -- if that INVITE gets routed to 
something that doesn't necessarily understand every kind of INFO that 
the caller's UA might want to send, very useful things can still happen.

/a

---

From: "Christer Holmberg" <[email-masked]>
Date: Sat, 17 Oct 2009 04:12:17 +0200

Hi, 

>>>requests) to be deleted. I don't believe there is sufficient
motivation to include this requirement and there is 
>>>certainly insufficient specification of what it would mean for it to
be there for it to be useful. If some future 
>>>package or usage really wants to affect rendezvous this way, then let
it specify it. Requiring that extra bits be 
>>>pumped around the network because something _might_ want to use it is
not the right thing to do.
>>      
>>I am not sure I agree this would be package specific. I think that,
for all packages, it could be useful to be able to 
>>do forking based this. Otherwise operators may have to rely on static
configuration in the network, which I thought is 
>>something we want to avoid.
>    
>
behavior has been borrowed. However, I don't think the 
>situations are particularly comparable.
>
support for an event package, then a proxy could 
>preferentially select it during target processing when a SUBSCRIBE came
in for the associated event package. This is 
>pretty watertight, because anything that doesn't support the event
package is going to be completely incapable of doing 
>INFO is radically different. You can't send INFO outside of a dialog --
so, by the time an INFO is on the wire, it's 
>ultimate destination has already been written in stone. The
corresponding INVITE is very different than the SUBSCRIBE 
>case -- if that INVITE gets routed to something that doesn't
necessarily understand every kind of INFO that the caller's 
>UA might want to send, very useful things can still happen.

I agree. 

But, I am not proposing that a proxy MUST fork based on Info Packages. I
only want to make sure the information is always there IF the proxy
wants to do it.

Regards,

Christer

---

From: Adam Roach <[email-masked]>
Date: Fri, 16 Oct 2009 21:51:37 -0500

On 10/16/09 21:12, Oct 16, Christer Holmberg wrote:
> But, I am not proposing that a proxy MUST fork based on Info Packages. 
> I only want to make sure the information is always there IF the proxy 
> wants to do it.

And I am agreeing with Robert's evaluation that these are largely 
semantic-free bits wasting space in the network for no demonstrable 
benefit. If a proxy declines to fork an INVITE to a registered contact 
on the basis of INFO packages, it is *doing* *the* *wrong* *thing*.

/a

---

From: "Christer Holmberg" <[email-masked]>
Date: Sat, 17 Oct 2009 19:08:05 +0200

Hi,
 
>benefit.
 
So, being able to fork based on capabilities (no matter whether they are info packages or something else) is not beneficial ?
 
>If a proxy declines to fork an INVITE to a registered contact on the basis of INFO packages, it is *doing* *the* *wrong* 
>*thing*.
 
I didn't say it would decline, but if it does serial forking it may give higher priority to a terminal which has registered support for certain info packages. Of course the forking decission may also be done in conjunction with criterias related to other types of capabilities.

As far as I remember, 3261 says that forking can be done pretty much based on ANY information - there is no "right" or "wrong" way from a protocol perspective. Are we now going to start telling operators how they shall do their forking?

I also think that being able to fork based on info packages fits very well into the do-what-I-say approach which we discussed during the service-id era...

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Sat, 17 Oct 2009 19:22:04 +0200

Hi,

>One thing that didn't survive the rewrite that I think we should work
back in is a note to implementors that an INFO might arrive from a peer
even before the first end-to-end provisional (because it 
>might win a race with an immediate 200 OK) and this is not an error.

You gave this comment to me earlier, in your previous comments. I
replied, but you never got back to me :)

The idea is that the UAS can start sending INFOs once the dialog (early
or final) has been established from the UAS's perpective. If I remember
corretly, that occurs when the UAS receives an acknolwedgement (PRACK or
ACK) to the response which established the dialog. In that case there
could be no race condition, because the UAS knows that the UAC has
received the 18x/200 response.

Regards,

Christer

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 19 Oct 2009 11:38:43 +0200

The presence of Recv-Info: foo in an INVITE request from UA1 means UA1 is capable of receiving foo. The presence of Recv-Info: foo in a REGISTER request from UA2 means that UA2 is capable of receiving foo. Preferentially routing an INVITE request from UA1 with Recv-Info: foo to UA2 assumes that the conjunction of UA1's ability to receive foo and UA2's ability to receive foo has some meaning. This may be true for some info packages, but how does a proxy know whether it is true for foo? I think if UA1 has a preference for a UA2 that can receive foo, UA1 needs some other way of expressing this preference. Something based on RFC 3841 would make sense.

John

> [mailto:[email-masked]] On Behalf Of Christer Holmberg
> Sent: 17 October 2009 18:08
> To: Adam Roach
> Cc: [email-masked]; SIPCORE; 
> Gonzalo Camarillo
> Subject: Re: [sipcore] WGLC comments (was Re: Draft new 
> version: draft-ietf-sipcore-info-events-01) - REGISTER and OPTIONS
> 
> Hi,
>  
> So, being able to fork based on capabilities (no matter 
> whether they are info packages or something else) is not beneficial ?
>  
> >If a proxy declines to fork an INVITE to a registered 
> contact on the basis of INFO packages, it is *doing* *the* *wrong* 
> >*thing*.
>  
> I didn't say it would decline, but if it does serial forking 
> it may give higher priority to a terminal which has 
> registered support for certain info packages. Of course the 
> forking decission may also be done in conjunction with 
> criterias related to other types of capabilities.
> 
> As far as I remember, 3261 says that forking can be done 
> pretty much based on ANY information - there is no "right" or 
> "wrong" way from a protocol perspective. Are we now going to 
> start telling operators how they shall do their forking?
> 
> I also think that being able to fork based on info packages 
> fits very well into the do-what-I-say approach which we 
> discussed during the service-id era...
> 
> Regards,
> 
> Christer
> 
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 19 Oct 2009 12:55:42 +0200

Hi, 

>The presence of Recv-Info: foo in an INVITE request from UA1 
>means UA1 is capable of receiving foo.

Correct.

>The presence of Recv-Info: foo in a REGISTER request from UA2 means
that UA2 is capable of receiving foo. 

Correct.

>Preferentially routing an INVITE request from UA1 with Recv-Info: foo
to UA2 assumes that the 
>conjunction of UA1's ability to receive foo and UA2's ability 
>to receive foo has some meaning. 

I guess the assumption is that if one is capable/willing to receive, it
is also capable/willing to send.

But, I agree that in some cases that is not true. For example, DTMF can
be one-way only. But, for other types of application the information
must be sent two-way in order for the application to work.

>This may be true for some info packages, but how does a proxy know
whether it is true for foo?

That's a good point.

So, maybe the way forward would be as Robert suggested: the specific
Info Package defines whether a UA shall include the Info Package in the
register or not.

>I think if UA1 has a preference for a UA2 that can receive foo, UA1
needs some other way of expressing this preference. 
>Something based on RFC 3841 would make sense.

That would be another alternative, yes: say that an Info Package that
wants this information need to register a feature tag. That of course
assumes that the feature tag can be defined as part of the Info Package
specification, because I don't think one should have to write a separate
RFC because of the feature tag.

Regards,

Christer

> > Cc: [email-masked]; SIPCORE; Gonzalo 
> > Camarillo
> whether they 
> > are info packages or something else) is not beneficial ?
> >  
> > I didn't say it would decline, but if it does serial forking it may 
> > give higher priority to a terminal which has registered support for 
> > certain info packages. Of course the forking decission may also be 
> > done in conjunction with criterias related to other types of 
> > capabilities.
> > 
> pretty much 
> > based on ANY information - there is no "right" or "wrong" 
> way from a 
> > protocol perspective. Are we now going to start telling 
> operators how 
> > they shall do their forking?
> > 
> fits very 
> > well into the do-what-I-say approach which we discussed during the 
> > service-id era...
> > 
> > Regards,
> > 
> > Christer
> > 
> >

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 19 Oct 2009 15:11:37 +0200

Hi Robert,

I want to thank you, and John, for the comments you've given. It's 7
pages in total, but I think it will improve the document even further :)

As you may have noticed, I am separating comments into separate e-mail
threads.

>This is my biggest comment for this version and I'm taking it 
>out of order to call attention to it. I think we've got some 
>confusion in the IANA considerations section that we need to 
>talk through. The document is setting up a 
>First-Come-First-Served registry using "Specification 
>Required" (which means that document has to exist somewhere, 
>but not necessarily one that's been "approved" by any 
>standards body), but we're calling such things "Standards 
>Track" in the registration. What is it that we're really 
>trying to set up?
>(If the current text survives, we'll need to be very explicit 
>with what "modified" means before this gets to IANA).
> 
>When thinking about this, we need to make sure section 7.11 
>is aligned to the conclusion.  Specifically, is it ok to have 
>a package registered that points to a company or individual's 
>website for the application procedures?

Do you think this is something I should request agenda time to discuss
at the meeting?

>The edit also addressed my concern about calling out to the 
>obsoleted INFO document for definition of behavor by leaving 
>removing any references of a normative nature. I think the 
>current approach will probably work, but I'm still thinking 
>it through and encourage review from this point of view from others.

I am not sure I understood correctly, but I have tried not to refer to
specific procedures in the RFC.

But, of course, we are not copy/pasting the RFC, so please let me know
if you think there is text which is problematic.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 19 Oct 2009 16:02:12 +0200

Hi Robert,

Below are my comments on your feedback which I haven't addressed in
separate e-mails.

--------

>The structure of section 4.4 is a little off. It would help 
>the logic flow to move the meaning of the last paragraph to 
>the first of the section. Words like "Normal processing as 
>required by [RFC3261] might require a failure response to be 
>sent to the INFO request. If no such requirement constrains 
>the UA, then..."

Fixed.

I can move the text from the last paragraph up to the first paragraph. I
suggest to also move the 200-for-legacy-INFO a 
little further up, so that the 200-response cases are first described,
and then the non-200 cases. 

--------

>Please make sure someone is on record as having done so 
>before this is pub-requested. That said, I noticed based on 
>looking at the diffs that "o"'s have been added for NOT and RFR. Why?

I can't remember why the "o" was added for NOT/REF. Eric/Hadriel?

Of course, REF CAN be sent within a invite dialog usage, and it is a
target refresh request, so I guess that is 
the reason why it was seen appropriate to allow to use it also for Info
Package indication.

However, I agree that it is probably doesn't make much sense to send
Info-Package in NOT/REF, so unless someone provides me with a
justification (or I find it myself) I can remove it.

--------

>issue is not applicable" with "or document why an issue is 
>not applicable".

Fixed.

--------

>calls out. What is the paragraph trying to accomplish?

The idea behind the text is that the SIP stack does not need to be aware
of the restrictions. 
Assuming the INFO request is otherwise ok, the SIP stack can generate a
200 OK response to 
the INFO, and the application layer will then deal with broken
restrictions associated with the package.

--------

>Section 8.2 ABNF: We've struggled before with the addition of 
>new header fields to the ABNF. Trying to use / as the 

Extension-method is used for adding INFO method name, not the new header
fields.

>Has anybody run the ABNF in this section through an automated checker?

I have been studying it very carefully, but I haven't used a checker. I
can look for one.

--------

>Section 11 should be titled "Security Considerations".  I 
>suggest Section 7.10 be relabelled "Info Package Security 
>Considerations".
>The first sentence from Section 11 (quoted below) is at odds 
>with the proposed First-come-first-served registration:
>"By eliminating multiple uses of INFO messages without 
>adequate community review and by eliminating the possibility 
>for rogue SIP UAs from confusing another User Agent by 
>purposely sending unrelated INFO requests, we expect this 
>document's clarification of the use of INFO to improve the 
>security of the Internet."

I guess this is related to the IANA issue you mentioned at the start of
your comments.

I am not sure how the text you refer to would go against the
first-come-first-served mechanism, though.

--------

>Unless there's a compeling reason to leave it as an appendix, 
>please move it into the main body of the document.

I can move it into the main spec.

The whole document used to suffer a little from the fact that we used
the justification draft as base for the mechanism, and that is also one
of the reasons why I re-wrote it :)

--------

>There are still several instances of using 2119 words to 
>constrain other documents or standards work rather than 
>constraining protocol.

I have had a look, and in some places I've decided to move from
uppercase to lowercase.

--------

>"identical" is the word you want to use here. I suggest "analogous"

Fixed.

--------

>  * The CSeq doesn't match the INVITE/200.

Fixed.

--------
 
>This wording is confusing. It essentially says "New things 
>follow this specification and old things don't. New things 
>should be prepared to act like old things when old things 
>talk to them". This backwards-compatibility requirement is 
>adequately captured elsewhere, I suggest deleting the paragraph.

Fixed.

(I assume you meant the 3rd paragraph)

--------
 
>Suggest adding "beyond its transaction" after "has no lifetime"

Fixed.

--------

>Suggest adding "even" as follows: "In that case, even if 
>multipart MIME is used,"

Fixed.

--------

>Page 12 second paragraph: Suggest adding a forward reference 
>to the section defining the 469 response code here where the 
>code is first mentioned.

Fixed.

--------

>Page 12 section 4.5 : "is normally generated by the SIP 
>stack" goes too far. Similarly the MUST requirement in the 
>2nd paragraph (sending a INFO) not really the constraint we 
>need. I suggest replacing the section with this text:
>"The Info Package Framework is designed to allow a SIP 
>stack to generate a response to an INFO message without 
>application interaction. As a result, Info Packages cannot 
>require bodies in INFO responses, require different response 
>codes, or otherwise require application information be placed 
>in the response to the INFO request. If the application has 
>information to send in the other direction, one alternative 
>available to it is sending a new INFO request."

Fixed.

I did some small changes to your suggested text, and replaced the
existing paragraph text with:

"The Info Package framework allows a SIP stack to generate a response to
an INFO request without application interaction. As a result, Info
Packages cannot require bodies in INFO responses, require different
response codes, or otherwise require the response to the INFO request to
contain application information. If the application needs to send
information in the other direction, it can send a new INFO request which
contains the information."

--------

>The first paragraph on page 16, last sentence says a request 
>without an Info-Package header MUST NOT contain an 
>Info-Package header :).

Fixed.

It's supposed to say:

"An INFO request without an associated Info Package header MUST NOT
contain an Info-Package header field,..." 

--------

>Page 17, Section 7.3: Why is there a requirement for a name 
>here that's separate from the header field value?

The name of the package could be rather long, but the header field value
would be shorter.

For example, the package name could be: "Info Package for DTMF
transport", while the header field value could be "infoDTMF". 

--------

>Page 17 Section 7.4 second paragraph: This could be read to 
>say two packages cant share the same parameter name. Can we 
>rewrite it to avoid that misinterpretation?

I suggest adding the following note:

"NOTE: Info Package parameters defined for specific Info Packages may
share the name with parameters defined for other Info Packages, but the
parameter semantics are specific to the Info Package for which they are
defined." 

--------
 
>Why hasn't the changelog been kept up? There are at least two 
>revisions worth of changes (the most recent will probably be 
>pretty hard to write). The working group will need to decide 
>whether to bring it up to date, delete the section before 
>requesting IETF-wide review, or add a section explaining the 
>gap in information before we proceed.

Since I only did the last update, I can only speak on behalf of that.
When I started to update the document based on comments I had received
earlier (by you and others) I tried to keep track of the changes.
However, at some point I decided to re-write most of the document,
instead of trying to fix pieces here and there, but at that point I soon
also realized that it would be very difficult to document the changes in
a sensible way. Also, many of the previously done updates weren't valid
anymore, which I why I also asked people who at any point had given
feedback to take a look at the new version.

--------

Nits:

NOTE: I fixed most of your nits findings, so I will only show the ones
where I have a comment.

--------

>Page 6 3rd paragraph, first sentence should have its commas 
>moved around or be rephrased. Suggest "If a UA supports the 
>Info Package mechanism, it uses the Recv-Info header field, 
>on a per-session bases, to indicate which Info Packages it is 
>willing to receive."

I agree. 

Based on John's comments, I will try to make the session vs dialog text
more consistant, but otherwise I have used your text.

>Page 15 section 6 1st paragraph 1st sentence: "the and a"? Is 
>this really two sentences that need to be teased back apart?

--------

>Page 17 section 7.3 : what should "**9" be?

Fixed.

It shall be a reference to the "IANA Considerations" section.

--------

>Suggest saying "more than one Recv-Info header field name."

I am not sure I agree. The text does not talk about the name of the
header field, but the presence of the header field in a SIP message.

--------

>from the Litmus draft? Are they still here and intact?

I don't know which they are, and due to the re-write I doubt they are
still there intact, so I removed the sentence. I think it is enough to
mention the Litmus draft.

>Appendix C : I think we should delete the "My, we have been" sentence.
>

I re-wrote Annex C, and made it shorter. It now more or less only
includes the >names of the individuals who have been involved in the
work.

NOTE: PLEASE LET ME KNOW IF YOU THINK THERE IS ANYONE WHO BELONGS TO BE
MENTIONED. NOBODY HAS BEEN LEFT OUT ON PURPOSE.

--------

Regards,

Christer

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 19 Oct 2009 16:19:24 +0200

Christer,

What if a UA1 that is not willing to receive info package foo wants to express a preference for a UA2 that can receive INFO package foo?

I agree extending caller preferences to cover this would be more work, but just including Recv-Info in REGISTER and pretending it solves the problem seems wrong to me.

In the past, have we ever agreed on a requirement for a UAC to be able to express a preference for a UAS that supports receiving a particular info package? I am concerned about whether this is really within the scope of this work item, which is already in WGLC.

John

> From: Christer Holmberg [mailto:[email-masked]] 
> Sent: 19 October 2009 11:56
> To: Elwell, John; Adam Roach
> Subject: RE: [sipcore] WGLC comments (was Re: Draft new 
> version:draft-ietf-sipcore-info-events-01) - REGISTER and OPTIONS
> 
> 
> Hi, 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Oct 2009 10:22:25 -0400

> RFC because of the feature tag.

You could define a new feature tag (e.g. "+sip.info") as part of this 
draft, where the possible values are info package names.

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Mon, 19 Oct 2009 09:56:47 -0500

[as chair]

> draft, where the possible values are info package names.

No.

We're in a *second* WGLC on this document. Now is not the time to add 
features. What we're supposed to be doing is fixing identifiable 
problems with the document.

If someone wants to tackle issues around INFO and rendezvous, that's 
grand. But we can't throw together a slapdash mechanism at the last 
possible moment and have any expectation that we've done it correctly. 
It's a new effort, and it needs to take place after we get this document 
out of the working group.

/a

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 19 Oct 2009 19:41:16 +0200

Hi,

I agree with Paul and John that a +sip.into feature tag would be the
best and cleanest thing.

Having said that, I do agree with Adam that we should not start adding
new features to THIS document at this point. We can write a separate
draft, which proposes a +sip.info feature tag. 

So, regarding REGISTER, would people be ok to allow (by indicating "o")
Recv-Info in REGISTER, but say that individual Info Packages must
describe if and how to use it? I THINK that is what Robert proposed.

And, are people ok with using the header in OPTIONS? OPTIONS is a
generic capabiltiy mechanism, where you can insert more or less
anything, so I see no reason why we should forbit Recv-Info.

Regards,

Christer

-----Original Message-----
From: Adam Roach [mailto:[email-masked]] 
Sent: 19. lokakuuta 2009 17:57
To: Paul Kyzivat
Cc: Christer Holmberg; Elwell, John; SIPCORE; Gonzalo Camarillo;
[email-masked]
Subject: Re: [sipcore] WGLC comments (was Re: Draft new
version:draft-ietf-sipcore-info-events-01) - REGISTER and OPTIONS

[as chair]

No.

/a

---

From: Adam Roach <[email-masked]>
Date: Mon, 19 Oct 2009 12:55:09 -0500

[as an individual]

> describe if and how to use it? I THINK that is what Robert proposed.

It sounds like a reasonable place to take things. Make sure the text 
clearly spells out that event packages expecting to make use of this 
mechanism must define how it is expected to work.

> anything, so I see no reason why we should forbit Recv-Info.

I have no problems with including it in OPTIONS.

/a

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 19 Oct 2009 21:40:17 +0200

> Sent: 19 October 2009 18:55
> To: Christer Holmberg
> Cc: Paul Kyzivat; Elwell, John; SIPCORE; Gonzalo Camarillo; 
> Subject: Re: [sipcore] WGLC comments 
> (draft-ietf-sipcore-info-events-01) - REGISTER and OPTIONS
> 
> [as an individual]
> 
[JRE] I can accept Christer's proposal, although my preference would have been to leave it out of REGISTER.

John

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 20 Oct 2009 08:12:51 +0200

Hi, 

>[JRE] I can accept Christer's proposal, although my preference would
have been to leave it out of REGISTER.

Would the following text be ok?

"This document allows a UA to insert a Recv-Info header field in a
REGISTER request. However, a UA SHALL NOT include a header value for a
specfic Info Package unless the specific Info Package specification
describes the how the header field value is to be intepreted and used by
the registrar, e.g. for forking decissions.

NOTE: Rather than using the Recv-Info header field for forking
decissions, it is recommended to use more appropriate mechanisms, e.g.
based on RFC 3840."

Regards,

Christer

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 20 Oct 2009 08:33:37 +0200

> Sent: 20 October 2009 07:13
> Cc: Paul Kyzivat; SIPCORE; Gonzalo Camarillo; 
> Subject: RE: [sipcore] WGLC comments 
[JRE] First I don't think "forking decisions" is the correct term. I think what we are talking about here is "determining request targets" (see 16.5 of RFC 3261). Such determinations may or may not lead to forking, but that is irrelevant here.

Also a nit: change "the how the" to "how the".

Otherwise this formulation seems OK.

John

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 20 Oct 2009 08:41:56 +0200

Hi,

>>describes the how the header field value is to be intepreted and used 
>>by the registrar, e.g. for forking decissions.
>> 
>[JRE] First I don't think "forking decisions" is the correct 
>term. I think what we are talking about here is "determining 
>request targets" (see 16.5 of RFC 3261). Such determinations 
>may or may not lead to forking, but that is irrelevant here.
> 

New text:

"This document allows a UA to insert a Recv-Info header field in a
REGISTER request. However, a UA SHALL NOT include a header value for 
a specfic Info Package unless the specific Info Package specification
describes how the header field value shall be intepreted and used 
by the registrar, e.g. in order to determine request targets.

NOTE: Rather than using the Recv-Info header field in order to determine
request targets, it is recommended to use more appropriate mechanisms,
e.g. based on RFC 3840."

I also did some changes to the OPTIONS text, in order to address
Robert's comment about "ignorning" the infomation in OPTIONS:

"If a UA sends an OPTIONS request, or a response, the UA SHALL include
Recv-Info header field in the message, and list the Info Packages that
it supports to receive.
 
NOTE: As for any other capability and extension, for a specific dialog
UAs need to indicate which Info Packages they are willing to receive
within that dialog."

Regards,

Christer