[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] [RAI] Re: RAI review of draft-ietf-sip-hitchhikers-guide-03
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 <jdrosen at cisco.com>*
>
> 15/11/2007 01:03
>
>
> To
> Avshalom Houri/Haifa/IBM at IBMIL
> cc
> sip at ietf.org, rai at ietf.org
> 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
> jdrosen at cisco.com FAX: (973) 952-5050
> http://www.jdrosen.net <http://www.jdrosen.net/>
> PHONE: (973) 952-5000
> http://www.cisco.com <http://www.cisco.com/>
>
> _______________________________________________
> RAI mailing list
> RAI at ietf.org
> https://www1.ietf.org/mailman/listinfo/rai
>
--
Jonathan D. Rosenberg, Ph.D. 499 Thornall St.
Cisco Fellow Edison, NJ 08837
Cisco, Voice Technology Group
jdrosen at cisco.com
http://www.jdrosen.net PHONE: (408) 902-3084
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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip