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

[Jonathan Rosenberg <[e-mail]>]

Text updated to say:

These extensions are general purpose enhancements to SIP, SDP and MIME 
that can
serve a wide variety of uses. However, they are not used for every
session or registration, as the core specifications are.


which matches the criteria defined in the document for core.

-Jonathan R.

Avshalom Houri wrote:
> 
> Jonathan,
> 
> Agree with your all replies.
> 
> One comment only:
> 
> First paragraph in section 5:
> 
>    These extensions are general purpose enhancements to SIP, SDP and
>    MIME that can serve a wide variety of uses.  However, they are not as
>    widely used or as essential as the core specifications.
> 
> Maybe should be changed to put more emphasize that these RFCs are not
> core specs and less on the wide deployment of them.
> Current wording seems to say (at least to me) that wide deployment was 
> the main
> criteria.
> 
> --Avshalom
> 
> 
> 
> 
> 
> 
> 
> *Jonathan Rosenberg <[e-mail]>*
> 
> 15/11/2007 01:03
> 
> 	
> To
> 	Avshalom Houri/Haifa/IBM@IBMIL
> cc
> 	[e-mail], [e-mail]
> Subject
> 	[RAI] Re: RAI review of draft-ietf-sip-hitchhikers-guide-03
> 
> 
> 	
> 
> 
> 
> 
> 
> Thanks for the comments, Avshalom. Responses below:
> 
> Avshalom Houri wrote:
>  >
>  > 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?
> 
> We had a whole thread on this, so I won't address this again here, but
> rather focus on your other comments.
> 
>  >
>  > 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.
> 
> No. Wide usage is not used to determine core or not. There is a litmus
> test defined for inclusion as a core spec:
> 
> <list style="symbols">
> 
> <t>For specifications that impact SIP session management, the
> extension would be used for almost every session initiated by a user
> agent
> </t>
> 
> <t>For specifications that impact SIP registrations, the extension
> would be used for almost every registration initiated by a user agent
> </t>
> 
> <t>For specifications that impact SIP subscriptions, the extension
> would be used for almost every subscription initiated by a user agent
> </t>
> 
> </list>
> 
> this definition is based entirely on the functionality of the spec and
> not judgement on its deployment.
> 
> The comments on deployment in the document are based on my own
> observation and awareness. Please feel free to suggest changes, that
> part of the description can only be improved with data from additional
> folks.
> 
>  >
>  > 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.
> 
> OK. Changing to symrefs helps a lot.
> 
>  >
>  > 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.
> 
> OK, I added a list in the introduction along with brief classification
> description.
> 
>  >
>  > 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.
> 
> changed this sentence to:
> 
> <t>Any specification that defines an extension to RFC 3261,
> where an extension is a mechanism that changes or updates in
> some way a behavior specified there.
> </t>
> 
> 
>  >
>  > <<<
>  >    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.
> 
> Actually BCPs can contain normative text and are, in many ways, very
> much like a PS.
> 
>  >
>  > 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.
> 
> The purpose here is to just enumerate the specs and describe each. I
> don't think the aim is to break it up here.
> 
>  >
>  > 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?
> 
> ok
> 
>  >
>  > <<<
>  >    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.
> 
> sure, but I don't think it would really be classified as a
> presence-related spec.
> 
>  >
>  > <<<
>  >    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?
> 
> ok
> 
>  >
>  > <<<
>  >    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?
> 
> Well, the line is fine, but connectivity preconditions is not about QoS
> as most folks think of it (i.e., bandwidth reservation).
> 
>  >
>  > 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.
> 
> moved.
> 
>  >
>  > 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.
> 
> OK.
> 
>  >
>  > 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.
> 
> I think its useful to list them.
> 
>  >
>  > 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?    
> 
> Hmm, well Brian had suggested that RFC 3325 has nothing to do with
> 'secure caller ID' so that one is definitely debatable.
> 
> 4474 definitely fits here. 3323 is kind of fuzzy, but I'll include.
> 
>  >
>  > 16.  Instant Messaging, Presence and Multimedia
>  > -----------------------------------------------
>  >
>  > Maybe create an applications section and put also conferencing as a type
>  > of an application.
> 
> Applications is really broad. The service URI stuff could be considered
> an app too. I think its valuable to have finer granularity than that.
> 
>  >
>  > 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.
> 
> Certainly its valuable, sufficiently so that simple-simple addresses it
> more completely and obviously separates IM from presence. But its not
> the emphasis of this document. If I split off presence there is only two
> docs in there (winfo and presence package), and only one in IM (3428) so
> this seems to argue for keeping them together. I did add a reference to
> simple-simple in the intro to let people know there is a more complete
> source of presence specs elsewhere.
> 
>  >
>  > 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).
> 
> done.
> 
>  >  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.
> 
> right, since they are not sip extensions.
> 
>  >
>  > The MSRP drafts seem to be forgotten?
> 
> Not a sip extension. RTP isn't listed here either.
> 
> -Jonathan R.
> -- 
> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> Cisco Fellow                                   Parsippany, NJ 07054-2711
> Cisco Systems
> [e-mail]                              FAX:   [phone]
> http://www.jdrosen.net <http://www.jdrosen.net/>                         
> PHONE: [phone]
> http://www.cisco.com <http://www.cisco.com/>
> 
> _______________________________________________
> RAI mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/rai
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[e-mail]
http://www.jdrosen.net                         PHONE: [phone]
http://www.cisco.com
_______________________________________________
Sip mailing list  http://www.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