Subject: [Sip] Fwd: I-D Action:draft-sparks-sip-3261-interop-statement-00.txt

From: Robert Sparks <[email-masked]>
Date: Mon, 2 Mar 2009 14:19:27 -0600

Also split out of steps-to-draft

Begin forwarded message:

> From: [email-masked]
> Date: March 2, 2009 8:30:02 AM CST
> To: [email-masked]
> Subject: I-D Action:draft-sparks-sip-3261-interop-statement-00.txt
> Reply-To: [email-masked]
>
> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
>
> 	Title           : RFC3261 Interop Statement
> 	Author(s)       : R. Sparks
> 	Filename        : draft-sparks-sip-3261-interop-statement-00.txt
> 	Pages           : 9
> 	Date            : 2009-03-02
>
> This document captures an outline of the interoperability statements
> that will be collected to construct an interoperability report for
> RFC 3261.  The outline is stil under review and should not be treated
> as complete, but will drive data collection at upcoming
> interoperability events.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-sparks-sip-3261-interop-statement-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 2 Mar 2009 16:12:09 -0500

Nice list.  Thanks for putting this together!

I propose you delete " - Demonstrate successful exchange of S/MIME protected entities".
I further propose the answer to "Right now there is nothing covering sips:. What do those statements need to look like?" is an empty line.
And I propose the answer to "How do we make a statement that captures we've found two implementations that discover their registrar through configuration rather than using URI resolution." Is we don't need to - the real world has done it for us.

And I like your bullet point in the middle of the Application-level features. :)

-hadriel

________________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Sparks
Sent: Monday, March 02, 2009 3:19 PM
To: SIP List
Subject: [Sip] Fwd: I-D Action:draft-sparks-sip-3261-interop-statement-00.txt

Begin forwarded message:

A New Internet-Draft is available from the on-line Internet-Drafts directories.

---

From: Nils Ohlmeier <[email-masked]>
Date: Mon, 02 Mar 2009 23:29:51 +0100

Hi Robert,

would appreciate it if you could add to the "URI specific features" (or 
to the "Extensibility mechanism"?) from my interop experience at SIPit:

- Demonstrate the correct usage of URIs with known and unknown 
parameters in Route URIs and Request-URI

Cheers
   Nils

Am 02.03.2009 21:19 Uhr, schrieb Robert Sparks:
>> *From: [email-masked] <mailto:[email-masked]>
>> *Date: *March 2, 2009 8:30:02 AM CST
>> *To: [email-masked] <mailto:[email-masked]>
>> *Subject: **I-D Action:draft-sparks-sip-3261-interop-statement-00.txt *
>> *Reply-To: [email-masked] <mailto:[email-masked]>
>>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------
>
> Sip mailing list  https://www.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: "Christer Holmberg" <[email-masked]>
Date: Tue, 3 Mar 2009 07:23:27 +0100

Hi,
 
A couple of questions:
 
1. The draft says "Demonstrate successful offer/answer exchange".
Offer/answer is one of the biggest interop issues, so I think we would
need to be a little more specific than that. We should probably have a
complete separate interop-statement on offer/answer...
 
2. For the things that shall be demonstrated, should there be references
to where the correct behavior is specified? It's difficult to
demonstrate correct behavior if you don't know what that correct
behavior is :)
 
Regards,
 
Christer

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Robert Sparks
Sent: Monday, March 02, 2009 10:19 PM
To: SIP List
Subject: [Sip] Fwd: I-D
Action:draft-sparks-sip-3261-interop-statement-00.txt

Begin forwarded message:

	Subject: I-D
Action:draft-sparks-sip-3261-interop-statement-00.txt 

	A New Internet-Draft is available from the on-line
Internet-Drafts directories.

	This document captures an outline of the interoperability
statements
	that will be collected to construct an interoperability report
for
	RFC 3261.  The outline is stil under review and should not be
treated
	as complete, but will drive data collection at upcoming
	interoperability events.

http://www.ietf.org/internet-drafts/draft-sparks-sip-3261-interop-statem
ent-00.txt

	Below is the data which will enable a MIME compliant mail reader
	implementation to automatically retrieve the ASCII version of
the
	Internet-Draft.

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 03 Mar 2009 10:23:22 +0000

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Christer Holmberg
	Sent: 03 March 2009 06:23
	To: Robert Sparks; SIP List
	Subject: Re: [Sip] Fwd:
I-DAction:draft-sparks-sip-3261-interop-statement-00.txt

	Hi,
	 
	A couple of questions:
	 
	1. The draft says "Demonstrate successful offer/answer
exchange". Offer/answer is one of the biggest interop issues, so I think
we would need to be a little more specific than that. We should probably
have a complete separate interop-statement on offer/answer...
	[JRE] Yes, I agree with this. I guess we need to draw a line
between SIP and SDP, but I think we should try to cover RFC 3264 aspects
to a reasonable degree.
	 
	John

	2. For the things that shall be demonstrated, should there be
references to where the correct behavior is specified? It's difficult to
demonstrate correct behavior if you don't know what that correct
behavior is :)
	 
	Regards,
	 
	Christer

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Robert Sparks
	Sent: Monday, March 02, 2009 10:19 PM
	To: SIP List
	Subject: [Sip] Fwd: I-D
Action:draft-sparks-sip-3261-interop-statement-00.txt

	Begin forwarded message:

		
		Title           : RFC3261 Interop Statement
		Author(s)       : R. Sparks
		Filename        :
draft-sparks-sip-3261-interop-statement-00.txt
		Pages           : 9
		Date            : 2009-03-02
		
		This document captures an outline of the
interoperability statements
		that will be collected to construct an interoperability
report for
		RFC 3261.  The outline is stil under review and should
not be treated
		as complete, but will drive data collection at upcoming
		interoperability events.

		
		
		Below is the data which will enable a MIME compliant
mail reader
		implementation to automatically retrieve the ASCII
version of the
		Internet-Draft.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 21 Mar 2009 10:28:33 -0400

Thanks, Robert.

Before commenting on the specific list of things, my meta-question is 
what exactly we plan to do with this list. I think we have agreed at 
previous meetings that we were not currently planning on taking SIP to 
draft. Do you think that has changed?

The document does say:

>  While not required by process until
>    advancing to Draft, such a report would provide useful information to
>    guide where we focus our energy maintaing the standard at Proposed.

its not clear to me, what this means. Will we take this list, run tests 
at sipit, and based on that define updates to 3261 to clarify? Does this 
imply that there are tests we're NOT running which we should be, that 
this draft helps us sort out?

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   111 Wood Avenue South
Cisco Fellow                                   Iselin, NJ 08830
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

---

From: Robert Sparks <[email-masked]>
Date: Sat, 21 Mar 2009 08:34:46 -0700

On Mar 21, 2009, at 7:28 AM, Jonathan Rosenberg wrote:

> Thanks, Robert.
>
> Before commenting on the specific list of things, my meta-question  
> is what exactly we plan to do with this list. I think we have agreed  
> at previous meetings that we were not currently planning on taking  
> SIP to draft. Do you think that has changed?
>
> The document does say:
>
> its not clear to me, what this means. Will we take this list, run  
> tests at sipit, and based on that define updates to 3261 to clarify?  
> Does this imply that there are tests we're NOT running which we  
> should be, that this draft helps us sort out?

Yes - what I'm currently planning to do is start to collect interop  
statements on this list, evolve the list over time, and use that body  
of information to further inform what's implemented, what's giving  
people trouble, and what's not being used.

>>> *Reply-To: [email-masked] <mailto:[email-masked] 
>>> >
>>>

---

From: "Doken, Serhad" <[email-masked]>
Date: Tue, 24 Mar 2009 00:39:04 -0700

Couple items for the list that popped to my mind (based on my share of interop issues I've seen) :

 *   Demonstrate correct recognition of when to retry requests and when to give up (401/423/403/480/500/503 etc use cases)
 *   Demonstrate correct implementations of retrying requests after the specified time internal when servers are busy/overloaded etc

Serhad

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Sparks
Sent: Monday, March 02, 2009 12:19 PM
To: SIP List
Subject: [Sip] Fwd: I-D Action:draft-sparks-sip-3261-interop-statement-00.txt

Begin forwarded message:

From: [email-masked]<mailto:[email-masked]>
Date: March 2, 2009 8:30:02 AM CST
To: [email-masked]<mailto:[email-masked]>
Subject: I-D Action:draft-sparks-sip-3261-interop-statement-00.txt
Reply-To: [email-masked]<mailto:[email-masked]>