(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
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
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