Subject: RE: [Sipping] Re: draft-gurbani-sipping-connection-guidelines-01

From: "Chris Boulton" <[email-masked]>
Date: Fri, 18 Feb 2005 10:23:04 -0000

Paul - thanks for looking at this doc.  Yes it is 'work-in-progress' so
all suggestions are greatly welcomed.  Some comments in-line.

Chris.

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 17 February 2005 18:58
To: sipping
Subject: [Sipping] Re: draft-gurbani-sipping-connection-guidelines-01

Thank you for doing this. It is a great start on an important subject! 
Somehow I missed the -00 version of this. I know this is a work in 
progress, so I don't want to nit pick on it. I have a few general points

to make:

Normative Language

I find the way the normative language is used somewhat difficult to 
follow. For instance, there are many places where it is stated that if 
there is a matching entry in a cache then it MUST be used. Yet placing 
things in the cache is optional, and rules for declaring cache entries 
stale are also arbitrary. So the MUSTs seem futile.

Perhaps the goal here is to say that the behavior specified in this 
guideline is optional, but that those who claim to follow it must behave

in a prescribed way. That may be helpful - it would be good to be clear 
about it. It would be even better if we could then find a way to signal 
when it is being followed.

[Chris Boulton] Taken on-board.  I agree that this needs more clarity.
Maybe we should be softening the text to provide more 'RECOMMEDNATIONS'
rather than strict orders.  I agree that it would be better to signal
support.  We fully intend looking at any potential extensions for
conveying support BUT wanted to get this draft discusses first to gauge
reaction/interst.

Duplication of text:

There is much duplication of use case text describing behavior of UAC, 
UAS, and Proxy. I was left with the feeling that while this was very 
similar, there must be differences or else it would not have been 
repeated. Yet it is both long enough and similar enough that discovering

the differences, if any, is hard. I was too lazy to bother. If there are

common behaviors that are used in different use cases, it would be 
helpful to describe them once, then call them out in the different 
contexts in which they may be used, identifying any variations that
apply.

[Chris Boulton] I will take a look at this - there are differences that
perhaps need to be conveyed in a more user friendly manner.

Connections, or TCP Connections

The introductory stuff talks about both TCP and SCTP. Down in the cases 
there is only reference to making TCP connections. Its not clear whether

these are supposed to apply to SCTP as well, via reader supplied 
analogies, or what. It would probably be sufficient to simply state that

use cases for SCTP are TBD.

[Chris Boulton] Agreed.  The document is intended to cover 'connection
orientated' protocols in general - we need to look at this for a more
balanced, generalized document. 

	Thanks,
	Paul

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

Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation.  All unauthorized use, disclosure or distribution is strictly prohibited.  If you are not the addressee, please notify the sender immediately and destroy all copies of this email.  Unless otherwise expressly agreed in a writing signed by an officer of Ubiquity Software Corporation, nothing in this communication shall be deemed to be legally binding.  Thank you.

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