[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Sip] 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
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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip