[Sip] RE: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03

["DRAGE, Keith \(Keith\)" <[e-mail]>]

At the risk of committing myself - definitely in.
 
Apart from one issue that I need to respond to Francois on which is
about documentation of Warning headers (i.e. adequately documenting the
changes as far as RFC 3261 and IANA are concerned, and anything the
PROTO shepherd (Dean) finds during his writeup, this document is
finished by the WG.
 
The outbound reference is not going to prevent the submission to IESG,
or the IESG approving it, merely delay the publication until outbound
gets an RFC number assigned. 
 
regards
 
Keith


________________________________

	From: Francois Audet [mailto:[e-mail]] 
	Sent: Tuesday, October 30, 2007 11:56 PM
	To: DRAGE, Keith (Keith); Avshalom Houri; [e-mail];
[e-mail]; [e-mail]
	Subject: RE: [RAI] RAI review of
draft-ietf-sip-hitchhikers-guide-03
	
	
	What about SIPS, which is already in hitchiker's guide, and
which is waiting on outbound because of a normative reference?


________________________________

		From: DRAGE, Keith (Keith)
[mailto:[e-mail]] 
		Sent: Tuesday, October 30, 2007 01:01
		To: Avshalom Houri; [e-mail]; [e-mail];
[e-mail]
		Subject: RE: [RAI] RAI review of
draft-ietf-sip-hitchhikers-guide-03
		
		
		(As WG chair)
		 
		Just a note that I should have included with the WGLC.
		 
		The intention with this document is to republish on a
recurring basis, and therefore to keep it up to date (say once a year or
so).
		 
		The 1st versions is intended to include gruu, outbound
and ice, but apart from that, anything that is not published in that
timeframe will probably be removed unless there is exceptional
justification for keeping it, with the idea that it will appear in the
next version.
		 
		regards
		 
		Keith


________________________________

			From: Avshalom Houri
[mailto:[e-mail]] 
			Sent: Monday, October 29, 2007 10:40 AM
			To: [e-mail]; [e-mail];
[e-mail]
			Subject: [RAI] RAI review of
draft-ietf-sip-hitchhikers-guide-03
			
			

			I have been assigned to review of
draft-ietf-sip-hitchhikers-guide-03 
			from the perspective of presence and the SIMPLE
group but ended up in 
			commenting on the whole document at the end. 
			
			For background on RAI-ART, please see the FAQ at

	
http://www.softarmor.com/rai/art/rai-art-FAQ.html
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>  
			
			Please resolve these comments along with any
other Last Call comments 
			you may receive. 
			
			In my opinion this draft is basically ready for
publication, but has 
			nits that should be fixed before publication. 
			
			Citations from the draft are marked by <<< text
from draft >>> 
			
			General comments 
			---------------- 
			
			By its nature there are a lot of reference to
drafts in the document. 
			It will take a lot of time for these documents
to become and RFC. 
			So how we are going to publish this as an RFC?
Since when the 
			referenced drafts will become an RFC, this draft
would have to be 
			updated with new drafts, will it be held in the 
			RFC ED queue for ever? 
			
			How do we gauge the usage of an RFC or a draft?
There are many places 
			here that it is said that this or that RFC/draft
got widely implemented 
			or not. 
			How it is measured? The wide implementation test
is used to decide 
			whether an RFC or draft are core or not and
therefore there should be 
			some text explaining how the wide implementation
was determined. 
			
			Better change RFC XXXX (before the reference
number in []) to the name 
			of the draft (with no version number), it will
make the ride smoother. 
			
			An introduction that details the various
grouping should be added. It 
			should include additional text on the group and
what was the criteria 
			for putting an RFC/draft in the group. 
			
			2.  Scope of this Document 
			-------------------------- 
			
			<<< 
			   o  Any specification that defines an
extension to SIP itself, where 
			      an extension is a mechanism that changes
or updates in some way a 
			      behavior specified in RFC 3261 
			>>> 
			
			"to SIP itself" sounds vague. It will be better
to say:"to RFC 3261" 
			instead. 
			Maybe there should be an earlier definition of
RFC 3261 as the SIP nucleus 
			(or the president of the galaxy) and that
RFCs/drafts mentioned in this 
			document are based on their relation to it. 
			
			<<< 
			   Excluded from this list are requirements,
architectures, registry 
			   definitions, non-normative frameworks, and
processes.  Best Current 
			   Practices are included when they normatively
define mechanisms for 
			   accomplishing a task. 
			>>> 
			    
			"normatively define" not sure what is meant by
normative with 
			respect to BCP. Seems like a contradiction in
terms. 
			
			3.  Core SIP Specifications 
			--------------------------- 
			
			If we think on presence as eventually replacing
registration, since it 
			carries much more information about the
availability of the user, 
			should we consider also presence as a towel? 
			
			<<< 
			   RFC 3261, The Session Initiation Protocol
(S):  RFC 3261 [1] is the 
			      core SIP protocol itself.  RFC 3261 is an
update to RFC 2543 [9]. 
			      It is the president of the galaxy [42] as
far as the suite of SIP 
			      specifications is concerned. 
			>>> 
			
			RFC 3261 is a very big document. Should it be
treated as one or it can 
			be divided into parts in this document e.g.
proxy, client etc.? I am not 
			sure what would be better. 
			
			4.  Public Switched Telephone Network (PSTN)
Interworking 
	
--------------------------------------------------------- 
			
			Regarding RFC 3578 
			Ugly in one corner of the galaxy may be
beautiful on the other of it :-) 
			
			7.  Minor Extensions 
			-------------------- 
			
			<<< 
			   RFC XXXX, Referring to Multiple Resources in
SIP (S):  RFC XXXX [44] 
			      allows a UA sending a REFER to ask the
recipient of the REFER to 
			      generate multiple SIP requests, not just
one.  This is useful for 
			      conferencing, where a client would like to
ask a conference server 
			      to eject multiple users. 
			>>> 
			
			Should not this be referred to in the
conferencing section also? 
			
			<<< 
			   RFC 4483, A Mechanism for Content Indirection
in Session Initiation 
			   Protocol (SIP) Messages (S):  RFC 4483 [89]
defines a mechanism for 
			      content indirection.  Instead of carrying
an object within a SIP 
			      body, a URL reference is carried instead,
and the recipient 
			      dereferences the URL to obtain the object.
The specification has 
			      potential applicability for sending large
instant messages, but 
			      has yet to find much actual use. 
			>>> 
			
			The specification has also potential for sending
large presence 
			documents via a URL. 
			
			<<< 
			   RFC 4583, Session Description Protocol (SDP)
Format for Binary Floor 
			   Control Protocol (BFCP) Streams (S):  RFC
4583 [91] defines a 
			      mechanism in SDP to signal floor control
streams that use BFCP. 
			      It is used for Push-To-Talk and conference
floor control. 
			>>> 
			
			Should not this be referred to in the
conferencing section also? 
			
			<<< 
			   RFC XXXX, Connectivity Preconditions for
Session Description Protocol 
			   Media Streams (S):  RFC XXXX [93] defines a
usage of the precondition 
			      framework [59].  The connectivity
precondition makes sure that the 
			      session doesn't get established until
actual packet connectivity 
			      is checked. 
			>>> 
			
			Should not this be referred to in the QoS
section also? 
			
			8.  Conferencing 
			---------------- 
			
			The Conferencing section should be before or
after "Instant Messaging, 
			Presence and Multimedia" as it is also an
application. See the comment 
			on whether presence is an application or not
later. 
			
			10.  Event Framework and Packages 
			---------------------------------- 
			
			Suggest to divide this section to event
framework section and to 
			packages section. The event framework should
include 3265, 3903, 4662 
			and subnot-etags which define the event
framework itself. 
			The other section will the packages sections
that will list the 
			packages. 
			
			Alternatively, many of the packages are
mentioned in their proper 
			section so it may be that all the event packages
can be fit into 
			their relevant section and there is not a need
for packages section. 
			
			11.  Quality of Service 
			----------------------- 
			
			<<< 
			   RFC 3313, Private SIP Extensions for Media
Authorization (I):  RFC 
			      3313 [61] defines a P-header that provides
a mechanism for passing 
			      an authorization token between SIP and a
network QoS reservation 
			      protocol like RSVP.  Its purpose is to
make sure network QoS is 
			      only granted if a client has made a SIP
call through the same 
			      providers network.  This specification is
sometimes referred to as 
			      the SIP walled garden specification by the
truly paranoid androids 
			      in the SIP community.  This is because it
requires coupling of 
			      signaling and the underlying IP network. 
			>>>       
			
			Understand that being a "truly paranoid" is a
virtue? :-) 
			
			15.  Security Mechanisms 
			------------------------ 
			
			Should not RFC 3323 (Privacy), RFC 3325
(Asserted-ID) and RFC 4474 
			(Identity) be mentioned here also?     
			
			16.  Instant Messaging, Presence and Multimedia 
			----------------------------------------------- 
			
			Maybe create an applications section and put
also conferencing as a type 
			of an application. 
			
			Including presence here with IM and multimedia
seems that presence is 
			regarded as an additional type of media. I am
not sure that I agree with 
			this. Presence is an enabler for many other
applications and it deserves 
			a section of its own. 
			
			It is very tempting to include the simple-simple
content here 
			(as an appendix?). If simple-simple is not to be
included here, there 
			should be at least a reference to simple-simple
as for presence 
			there are so many documents that are essential
for doing presence and 
			are not mentioned here (e.g. watcher format,
RPID, presence rules, 
			partial notify and publish and many many more).
Roughly counting, there 
			are about 20-25 RFCs/drafts that are very
relevant to presence that are 
			mentioned in simple-simple in addition to the
ones that are mentioned here. 
			
			The MSRP drafts seem to be forgotten? 
			
			Thanks 
			--Avshalom
			

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