Subject: RE: [Sip] INFO Packaging -- draft-willis-sip-infopackage-00

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Tue, 14 Jan 2003 16:26:31 -0000

In principle, the idea looks good to me.

I would note that the proposal invalidates existing usages of the INFO method, as presumably all usages of INFO carry the new header Info-Type and the dialog should presumably be created carrying the Allow-Info header. Assuming we allow this constraint, which is OK by me but some people who have already implemented it might shout, then it would seem better to document this by obsoleting the existing version of INFO (RFC 2976) and creating a new one; this would allow the method specification to be aligned with RFC 3261 rather than RFC 2543 (and also allow its interaction with all the other new RFCs to be specified - although I assume this interaction is fairly minimal - the only impact I can see is the inclusion of the Allow-Events header in INFO).

From this proposal there is possibly a minor impact on RFC 3398. This document requires a gateway to support the INFO method. Presumably it would be appropropriate that the gateway now advertises the type of INFO usage that it supports (i.e. ISUP encapsulation), and this would be a requirement that should be in RFC 3398 rather than elsewhere.

Strangely enough, we seem to have absolutely no examples of the use of INFO to carry mid call information, so no changes are generated as a result of this. However the advertising of the capability would have impact on http://www.ietf.org/internet-drafts/draft-ietf-sipping-pstn-call-flows-01.txt, as might be expected.

The example in section 4.1 of RFC 3204 would also be invalidated by the proposal as it stands.

Detailed comments:

1)	I assume that reference [5] should be to RFC 3261, rather than RFC 3162. Correction required both in the body of the document and in the references themselves.

2)	In section 4 and 5, I am unsure why the Supported header needs to be in all requests. Surely INFO can only be used in an INVITE dialog, therefore it is sufficient to put it in the INVITE (and of course OPTIONS). Also why is the same requirement duplicated in both sections. Perhaps the use of the option-tags should be brought out to a separate section, e.g. incorporated into 7.1. Note that there is a typo at the end of the clause 5 text on the option-tags. It is also not practice to put header names in quotation marks.

3)	Figure 1 and figure 2 should really be tables rather than figures, and should show all the methods currently defined - see RFC 3455 for an example.

4)	The Allow-Events header only appears in requests. I assume the same considerations apply to the new Allow-Info header and this should be appropriately indicated in figure 1.

5)	In figure 2, surely the Info-Type header only applies to requests and this should be indicated appropriately, as only the INFO request can carry the data.

6)	The IANA considerations section is missing the Info-Type header.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked] 

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]]
> Sent: 14 January 2003 02:22
> To: [email-masked]
> Subject: [Sip] INFO Packaging -- draft-willis-sip-infopackage-00
> 
> 
> 
> It only seemed appropriate to follow up my previous assumably 
> eloquent but
> frequently misspelled exhortations by following my own advice 
> and "sending
> text".
> 
> The resulting draft has been submitted to the archive and should be
> announced in due course. In the interim, you may wish to 
> retrieve it from:
> 
> http://www.softarmor.com/sipwg/drafts/draft-willis-sip-infopac
kage-00.html

or

http://www.softarmor.com/sipwg/drafts/draft-willis-sip-infopackage-00.txt

Or, if you just LIKE looking at XML source or wish to fix some of my
probable glaring errors,

http://www.softarmor.com/sipwg/drafts/draft-willis-sip-infopackage-00.xml

I'd like to caveat that this is a rough first draft -- I just sat down and
banged it out this afternoon, and only Adam Roach has seen any of it so far,
and that was in small bits.

thanks

--
Dean

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Dean Willis" <[email-masked]>
Date: Tue, 14 Jan 2003 12:57:31 -0600

Keith said:
> 3)	Figure 1 and figure 2 should really be tables rather 
> than figures, and should show all the methods currently 
> defined - see RFC 3455 for an example.
. . . 
> 5)	In figure 2, surely the Info-Type header only applies 
> to requests and this should be indicated appropriately, as 
> only the INFO request can carry the data.

We have SO got to stop trying to to update these tables. It's a cubic
expansion problem, and I don't think it's actually possible to get right, as
new stuff appears between the writing and the publishing.

Any ideas on alternatives? Can we simply stop tracking this? Does it need to
be turned into some kind of IANA registry? How could we approach the problem
if we made it a registry?

--
Dean

---

From: "Adam Roach" <[email-masked]>
Date: Wed, 15 Jan 2003 17:25:16 -0600

----- Original Message ----- 
From: "Drage, Keith (Keith)" <[email-masked]>
> I would note that the proposal invalidates existing usages
> of the INFO method, as presumably all usages of INFO
> carry the new header Info-Type and the dialog should
> presumably be created carrying the Allow-Info header.

Note well that we had a completely congruent situation
with SIP events (PINT had already made it to RFC),
and the solution was both straightforward and
uncontroversial.

Dean: you should probably add a section that's a cut,
paste, and tiny edit from section 3.3.8 of RFC 3265.

/a