What about SIPS, which is already in hitchiker's guide, and which is
waiting on outbound because of a normative reference?
________________________________
From: DRAGE, Keith (Keith) [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 30, 2007 01:01
To: Avshalom Houri; [EMAIL PROTECTED]; [email protected];
[EMAIL PROTECTED]
Subject: RE: [RAI] RAI review of
draft-ietf-sip-hitchhikers-guide-03
(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
________________________________
From: Avshalom Houri [mailto:[EMAIL PROTECTED]
Sent: Monday, October 29, 2007 10:40 AM
To: [EMAIL PROTECTED]; [email protected]; [EMAIL PROTECTED]
Subject: [RAI] 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
<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?
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 [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
