[Speermint] RE: Closing Issue SIP Interoperablity (Section 4.3: draft-khan-ip-serv-arch-02)

Why do you think you can get away with ignoring such things as, say
"UPDATE"?  Do you really think we can say "implementations should not assume
UPDATE will work across the peering point"?

I think closing off this issue will require an extended discussion.

Brian

-----Original Message-----
From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] 
Sent: Friday, May 26, 2006 2:49 PM
To: Francois D. Menard; Brian Rosen; James McEachern; Stastny Richard;
speermint@ietf.org; Michael Hammer (mhammer); David Meyer
Subject: Closing Issue SIP Interoperablity (Section 4.3:
draft-khan-ip-serv-arch-02)

Thank you for all suggestions and comments on the SIP Interoperability
(Section 4.3: draft-khan-ip-serv-arch-02) paragraph in Speermint Peering
Architecture draft. Based on the discussion, I would propose to close
the issue by replacing the current paragraph,
"SIP Interoperability:TBD" with the following paragraph.

"SIP Interoperability: SPEERMINT Signaling Function (SF) in general
should support all SIP RFCs identified in the SIP hitchhiker's guide.
The SF must minimally support RFC 3261, 3263, 3325, and 3326. 

A SPEERMINT SIP Profile document would recommend a rationale set of SIP
profiles to perform smooth interoperability. The document will also
contain information on the population of the header fields, particularly
in context with phone numbers (e.164 and non-E.164).

A SPEERMINT SIP Flow Document would recommend call flows and
establishment of two-way TLS connections."

Please do not criticize! Instead, suggest another paragraph or a better
version of this paragraph.

Sohel Khan, Ph.D.
Technology Strategist
Sprint-Nextel
913-794-1470 (office)
913-486-3145 (cell)

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint