[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Sip] RE: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03
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
What
about SIPS, which is already in hitchiker's guide, and which is waiting on
outbound because of a normative reference?
(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
_______________________________________________
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