Subject: Re: [sipcore] WGLC draft-ietf-sipcore-info-events-03.txt

From: "Elwell, John" <[email-masked]>
Date: Thu, 7 Jan 2010 11:25:13 +0100

I have read the document again - apologies for being late. I consider it ready to go with the exception of the following minor issues:

1. The last paragraph of section 1 seems to be redundant (the same text appears in section 2).

2. In section 3.2.1:
"   An INFO request can be associated with an Info Package (see X), or
   associated with a legacy INFO usage (see Y)."
What are "X" and "Y"?

3. In section 3.2.1:
"  A UA MUST NOT use the INFO method outside an invite dialog usage.
   UAs indicate, per-dialog basis, for which Info Packages they are
   willing to receive INFO requests.  The set of Info Packages cannot
   automatically be used within other dialogs."
This mixing up the contexts of sending and receiving INFO requests, and also strays into subject matter that is the concern of section 4. It could beneficially be shortened to:
"A UA MUST NOT send an INFO request outside an invite dialog usage and MUST NOT send an INFO request for an Info Package if the remote UA on that dialog has not indicated willingness to receive that Info-Package."

4. In 3.2.2:
" If a UA receives an INFO request associated with an Info Package, and
   the message body part associated with the Info Package contains a
   message body MIME type that the UA support, but which usage is not
   defined for the specific Info Package, it is RECOMMENDED that the UA
   sends a 415 (Unsupported Media Type) response.
The wording isn't quite right, and in particular the received message body part is NOT associated with the Info Package - although I guess if it has Content-Disposition Info-Package it is kind of linked to the Info Package, but this Content-Disposition value is not introduced until 3.3.1. I think it should say (also fixing some other nits):
"If a UA receives an INFO request associated with an Info Package and the message body part with Content-Disposition 'Info-Package' (see 3.3.1) has a MIME type that the UA supports but not in the context of that Info Package, it is RECOMMENDED that the UA send a 415 (Unsupported Media Type) response."

5. In 3.3.1:
"UAs MUST conform to [RFC5621] to support multipart body parts."
Is this intending to say:
"UAs MUST support multipart body parts in accordance with [RFC5621]"
or
"UAs that need to use multipart body parts MUST do so in accordance with [RFC5621]"?
I suspect the first interpretation is intended, but a reader could interpret it either way.

6. In 3.3.1:
"NOTE: Some SIP functions that are orthogonal to INFO can insert body
   parts unrelated to the Info Package."
I am not sure a reader would understand this. Also, for legacy usage, a body part could be related to INFO (i.e., not "orthogonal") but not related to any Info Package. A possible improvement would be:
"NOTE: An INFO request can also contain other body parts that are meaningful within the context of an invite dialog usage but are not specifically associated with the INFO method and the application concerned."

7. In 4.2.2:
"A UA can an empty Recv-Info header
   field"
A verb is missing here - should it be "A UA can use an empty Recv-Info header field"?

8. In 4.2.2:
"or that that the UA wishes to only receive INFO
   request for one of the Info Packages."
Change "request" to "requests".

9. In 7.3:
"or other user plane data transport mechanisms"

For consistency with 7.4.2, should "user plane" be "media plane"?

10. In 7.4.2.1:
"...and there is no need
   for the SIP signaling intermediates routing to examine the
   information..."
This does not make sense. I think the word "routing" should be dropped, and perhaps change "intermediates" to "intermediaries".

11. In 7.4.3:
"Another alternative is to use a totally externally signaled channel,
   such as HTTP [RFC2616]."
I don't know what "a totally externally signaled channel" means - perhaps it should say "a SIP-independent mechanism".

12. In 8.1:
"This section describes the syntax extensions required for the INFO
   method."
Two problems. Firstly, the syntax extensions are not in this section (8.1), they are in 8.2.
Secondly, 8.2 also defines syntax for Recv-Info, which is not part of the INFO method as such.

13. In 10.1:
"if applications
   associated with the Info Package requires it"
Change "requires" to "require".

14: In 10.1:
"  Section 7.4 describes alternative mechanisms, which should be
   considered as part of the process for solving a specific use-case,
   when for transporting application information."
"when for" does not make sense. I suspect it should say "when there is a need for".

15. In 10.3:
"overlap description" - change to "overall description".

16. In 10.4:
"to be identify" - change to "to identify".

John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Gonzalo Camarillo
> Sent: 24 December 2009 10:31
> To: SIPCORE
> Subject: Re: [sipcore] WGLC draft-ietf-sipcore-info-events-03.txt
> 
> Hi,
> 
> this WGLC ends today and we have not received *any* comments.
> 
> Cheers,
> 
> Gonzalo
> 
> Gonzalo Camarillo wrote:
> > Hi,
> > 
> > we are half-way through this WGLC and no comments have been 
> received. 
> > You need to fire up! ;o)
> > 
> > Cheers,
> > 
> > Gonzalo
> > 
> > Gonzalo Camarillo wrote:
> >> Folks,
> >>
> >> Christer has submitted a new version of the INFO Events 
> draft (see email 
> >> below) that is supposed to address all the comments 
> received so far. 
> >> Since there have been extensive discussions on this topic 
> since the last 
> >> time we WGLCed this draft, we are going to WGLC it again.
> >>
> >> http://tools.ietf.org/html/draft-ietf-sipcore-info-events-03
> >>
> >> So, please, have a look at this new version and let us 
> know whether or 
> >> not you also think all comments have been addressed. Of 
> course, you are 
> >> also welcome to submit new comments should you have some. 
> This WGLC will 
> >> end on December 24th.
> >>
> >> Thanks,
> >>
> >> Gonzalo
> >> SIPCORE co-chair
> >>
> >> -------- Original Message --------
> >> Subject:     [sipcore] Draft new version: 
> draft-ietf-sipcore-info-events
> >> Date:     Wed, 2 Dec 2009 09:59:24 +0100
> >> From:     Christer Holmberg <[email-masked]>
> >> To:     <[email-masked]>
> >>
> >>
> >>
> >>
> >> Hi,
> >>
> >> I've submitted a new version of the info draft. Hopefully 
> all comments
> >> and feedback have now been addressed.
> >>
> >> The biggest changes are:
> >>
> >> - Section 4.2: The usage of the Recv-Info header has been 
> clarified,
> >> some simple rules have been added, and there were some 
> discussions that
> >> since the re-INVITE fallback issue also affects Recv-Info (if you
> >> receive a Recv-Info in a 18x to a re-INVITE, and the re-INVITE then
> >> fails) and that we need some words about that. The text 
> now says that IF
> >> the request contains a Recv-Info header, the response must 
> also contain it.
> >>
> >> - Section 11.4: Contains new wording about the IANA process for
> >> registering info packages, including the expert review etc.
> >>
> >> - Section 12: Additional examples have been added
> >>
> >>
> >> Please note that I did NOT remove Recv-Info in PRACKs, 
> since there in my
> >> opinion was no concensus to do so.
> >>
> >>
> >> The draft can also be found at:
> >>
> >> 
> _http://users.piuha.net/cholmber/drafts/draft-ietf-sipcore-inf
> o-events-03.txt_ 
> >>
> >>
> >>
> >>
> >> Regards,
> >>
> >> Christer
> >>
> >>
> >>
> >> 
> --------------------------------------------------------------
> ----------
> >>
> >> _______________________________________________
> >> sipcore mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/sipcore
> > 
> > _______________________________________________
> > sipcore mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/sipcore
> > 
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 12 Jan 2010 21:45:10 +0100

Hi John, 

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

>1. The last paragraph of section 1 seems to be redundant (the same text appears in section 2).

Personally I think it is useful to have the text in both places, but I can remove it from section 1 if nobody objects.

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

>   associated with a legacy INFO usage (see Y)."

X = Reference to section 4.
Y = Reference to section 9.

I'll fix that.

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

>"A UA MUST NOT send an INFO request outside an invite dialog usage and MUST NOT send an INFO request for an Info Package if the remote UA on that dialog has not indicated willingness to receive that 

Looks good. I'll fix that.

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

>The wording isn't quite right, and in particular the received message body part is NOT associated with the Info Package - although I guess if it has Content-Disposition Info-Package it is kind of linked 
>to the Info Package, but this Content-Disposition value is not introduced until 3.3.1. I think it should say (also fixing some other nits):
>
>"If a UA receives an INFO request associated with an Info Package and the message body part with Content-Disposition 'Info-Package' (see 3.3.1) has a MIME type that the UA supports but not in the context 
>of that Info Package, it is RECOMMENDED that the UA send a 415 (Unsupported Media Type) response."

Yes. I'll fix that.

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

>I suspect the first interpretation is intended, but a reader could interpret it either way.

Yes, the first interpretation is correct. I'll fix it according to the text you suggest.

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

>6. In 3.3.1:
>"NOTE: Some SIP functions that are orthogonal to INFO can insert body parts unrelated to the Info Package."

I think the text was provided by Paul, but I think the text you suggest is more clear, so I'll fix it according to that. I doubt Paul will mind :)

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

>7. In 4.2.2:
>"A UA can an empty Recv-Info header field"

Yes. I'll fix that.

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

>8. In 4.2.2:
>"or that that the UA wishes to only receive INFO request for one of the Info Packages."

I'll fix that.

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

>For consistency with 7.4.2, should "user plane" be "media plane"?

Yes. I'll fix that.

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

>10. In 7.4.2.1:
>"...and there is no need for the SIP signaling intermediates routing to examine the information..."

Yes. I'll use "intermediaries".

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

>11. In 7.4.3:
>"Another alternative is to use a totally externally signaled channel, such as HTTP [RFC2616]."

Yes. I'll fix that.

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

>12. In 8.1:
>"This section describes the syntax extensions required for the INFO method."

Yes, but chapter 8.1 gives a generic description of chapter 8.

>Secondly, 8.2 also defines syntax for Recv-Info, which is not part of the INFO method as such.

I can add "...and the Recv-Info header field" to the sentence above.

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

>13. In 10.1:
>"if applications associated with the Info Package requires it"

I'll fix that.

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

>"when for" does not make sense. I suspect it should say "when there is a need for".

Yes. I'll fix that.

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

>"overlap description" - change to "overall description".

I'll fix that.

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

>"to be identify" - change to "to identify".

I'll fix that.

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

Thank You very much for the comments!

In addition, I've been asked to do the following fixes (thanks to Arun Arunachalam for providing them):

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

17. In 3.2.1:

Change:

"The construction of the INFO request is the same as any other request within an existing invite dialog usage."

...to:

"The construction of the INFO request is the same as any other non-target refresh request within an existing invite dialog usage as described in Section 12.2 of RFC 3261."

If nobody objects, I'll do that change.

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

18. In 5.1:

Change:

"Proxy-Authenticate         401      m
 Proxy-Authenticate         407      o"

..to:

"Proxy-Authenticate         401      o
 Proxy-Authenticate         407      m"

If nobody objects, I'll do that change.

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

19. In 12.1.2:

"The UAS sends a 200 (OK) response back to the UAC, where the UAS
indicates that it is willing to receive INFO requests for Info Packages R."

Modify to "Packages R, T".

If nobody objects, I'll do that change.

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

20. In 6.1:

>Can a proxy add / modify / delete the Recv-Info or Info-package?
>
>   From my understanding of the draft, the answer is no since these headers are typically
>   processed by the endpoints. It will be helpful to add the "proxy" column and set the 
>   value to "blank" (similar to Accept header in Section 20.1 of RFC 3261).

If nobody objects, I'll do that change.

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

21. Proxy processing of INFO requests

>It will be helpful to explicitly mention the proxy behavior of INFO requests i.e. add content
>similar to SUBSCRIBE request handling in Section 3.1.5 of RFC 3265

Since INFO is a mid-dialog request, there is no need to talk about record-routing. The only text I can think of is:

"Proxies need no additional behavior beyond that described in RFC3261 to support INFO."

I can add a new section (3.2.3) if people think it's needed.

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

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 13 Jan 2010 09:01:19 -0500

> I think the text was provided by Paul, but I think the text you suggest is more clear, so I'll fix it according to that. I doubt Paul will mind :)

No, I don't object.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 14 Jan 2010 08:55:41 +0100

Hi,

I've submitted a new version (-04) of info-events, based on some additional WGLC comments.

Most changes are editorial, but a new short section, 3.2.3 (SIP Proxies), has been added.

The document can also be found at:

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

Regards,

Christer