Subject: [RAI] RAI-ART Review Comments for draft-ietf-sip-hitchhikers-guide

From: "Brian Stucker" <[email-masked]>
Date: Thu, 8 Nov 2007 15:09:18 -0600

Jonathan,

Thanks for putting the document together. It took quite awhile to just
review it! 

Here are the comments that I have as part of the RAI-ART review of the
document. Apologies for the probable repeats in here from list comments,
I was not able to try to correlate my comments with others on the
various reflectors.

I tried to break my comments up by section and document so hopefully
it's coherent in plain-text.

Regards,
Brian

----

Section 1:

   This document itself is not an update to RFC 3261
<http://tools.ietf.org/html/rfc3261>  or an extension to
   SIP.  It is an informational document, meant to guide newcomers,
   implementors and deployers to the SIP suite of specifications.

May want to change "meant to guide newcomers, implementors and deployers
to the SIP suite of specifications" since many of the documents are not
predicated upon SIP itself. For example, RFC-4566, 3388, 3264. Also, I
don't think we want to imply that this document is exhaustive. Perhaps
"It is an information document, meant to introduce newcomers,
implementors and deployers to many of the important IETF specifications
associated with SIP. Specifications referenced by this document were
chosen based on working group consensus and the list presented here is
not intended to be exhaustive or confer any special status over
documents not included."

Might also want to include some pointers to the relevant WG webpages to
give newcomers a place to go for further information. As well as include
some boilerplate about the dangers of implementing I-D's before they
become RFCs (I think this was already discussed somewhat on the RAI
mailing list).

Section 2:

	Although I agree that documents defining relevant registries
should be excluded, what about pointers to the registries themselves?
Seems like some of the interop problems we wind up with are due to
disregard or lack of visibility of the IANA registration process to
implementors.

Section 3:

RFC3261: 

	I think it would be useful to provide a reverse-lookup list of
RFCs that formally update 3261 under the 3261 entry: RFC-3583, RFC-4320
and RFC-4916. There is a statement under 4320 that it formally updates
3261, but there is no mention under 4916 that it formally updates 3261,
it just looks like any other extension. Putting a pointer to the SIPS
work as a TBD formal update to 3261 would also be good as well as
collapsing the "essential corrections to SIP" under the 3261 entry so
that people don't skip over that material would be good as well.

RFC3264:

	Should we perhaps put a pointer here to the offer/answer draft
for further clarification of 3264 since it seems pretty clear that the
baseline specification did not entirely capture all of the interactions
that arise in implementations?

RFC3325:

	May want to remove the word "secure" from the description of the
P-Asserted-ID header description. P-Asserted-ID does not confer any
security of the caller ID information. It's the trust domain that
provides the security in contrast to a mechanism like RFC-4474. 

RFC3581:

	Rport is necessary to routing a response through a NAT, but does
not solve NAT traversal for SIP signaling. Perhaps a pointer to outbound
under this RFC would be useful to highlight what you don't get with
rport that you need to fully address NAT traversal issues, or simply
remove it entirely and rely on folks to go to the NAT traversal section
to discover it there as it's not necessary at all if you have no NATs to
traverse (ALGs and SBCs aside).

RFC4474:

	I don't think it's necessary that we should highlight the
deployment size of the various RFCs in this way, especially given that
the RFC is much newer (and has more complicated requirements) than
RFC3325.

SIPS:

	Should note that this will formally update RFC3261 when approved
to highlight that newcomers should ignore what's in RFC3261.

Section 4:

RFC2848/3910:

	If this has seen little deployment and is very narrowly scoped,
then why are we including it in the guide? 

RFC3372:

	Widespread implementation in a limited deployment model. It
should be noted that it's usage is intended to be temporary as ISUP
endpoints are obviated from the network.

RFC3960:

	Early media is not just generated by the PSTN. We should be fair
here and acknowledge that 3960 does not solve all of the various issues
associated with early media (without enumerating them). We all know this
to be the case, so just a sentence or two should suffice to warn the
reader.

RFC3959:

	We should highlight that this specification has not seen
widespread deployment. As of a few IETFs ago nobody indicated that they
had developed anything with regards to this specification when asked at
a working group meeting. This is only important in that 3960 does not
solve all of the early media issues.

Shouldn't we have an entry in this section for RFC3966 to cover tel
URIs?

Section 5:

RFC3262:

	PRACK is complicated, for sure, but it's used for more than just
PSTN interworking and is more than mildly deployed depending upon the
environment.

RFC3311:

	..but can be used to initiate a reliable request during session
establishment when a re-INVITE is not possible. This is key for
conveying information to an originator that cannot be conveyed in a
response either due to offer/answer complications or because a header is
not allowed in a response message type. We should also point out here
that when UPDATE is used to convey SDP, support for RFC3262 is required
in some scenarios. I don't think this is widely recognized. Should also
call out that it can be used to convey mid-call information as well.

RFC3608:

	You've captured the client perspective of the usage of
service-route, but from a server perspective, it's used by proxies to
capture the route set of a registration to know how to route future
requests on behalf of the client. In this role it has seen greater
deployment and applicability.

RFC 3841:

	Should probably call out the relationship between this RFC and
3840.

Need to remove duplicate entry for SDP negotiation under PSTN
interworking.

RFC4244:

	Should remove reference to voicemail here. It has broader scope.
RFC4758 is intended for this purpose now (later comment).

Shouldn't we have an entry in this section for RFC3880, CPL?

Section 6:

RFC3605:

	Should this be here and under the core specifications section? I
don't see this attribute show up in SDP very often (pre-ICE), but it is
necessary for some NAT traversal solutions. Perhaps only have a
reference to it here? Outside of NAT traversal, is there a primary
reason to have this RFC or ICE in the core specifications section?

OUTBOUND:

	Doesn't outbound satisfy the requirements of a broadly
applicable extension to SIP? Seems like if ICE is a core specification,
that OUTBOUND should be considered one as well?

RFC3890:

	It's used extensively in other SDOs, paricularly wireless.

RFC4730:

	Should probably explain here briefly, that 2833/4733 is most
commonly used to convey DTMF for SIP deployments, but the difference is
that KPML does it on the signaling path as opposed to the media path.
This is somewhat important given the low current deployment of KPML.

Section 13:

	Perhaps we should add an entry here for RFC4896 or make a note
under the entry for RFC3486 that RFC4896 updates both RFC3486 and
RFC3485 which is the static dictionary for SIP (which provides the
explicit coupling between SIGCOMP and SIP eluded to in the draft text).
The important bit for an entry to RFC3485 is that there are a few bugs
in the dictionary such that you'd need to refer to section 12 of RFC4896
to come up with a BCP implementation.

Section 14:

I think we should add an entry for RFC4758 to capture the voicemail
service URI as another important service URI RFC.

Section 15:

RFC3853:

	May want to state that RFC3853 'formally' updates RFC3261, and
put a pointer to this from the core specifications section as a result
since it's a correction to 3261.

RFC3893:

	Should RFC3893 entry simply say something to the effect of 'use
RFC4474', or be dropped altogether?

RFC3329:

	There are now three possible security models now in 3GPP: HTTP
DIGEST, AKA, and early-IMS. As early-IMS doesn't really involve much in
the way of security mechanisms within the SIP protocol, the coexistance
of it with digest or AKA seems to be very probable. Perhaps we should
just remove the last sentence and leave it up to the reader to decide if
it's needed for their purpose.

Section 16:

Shouldn't we perhaps move RFC4796 from section 7 to this section?

Section 17:

Providing a pointer off to ECRIT seems useful here.

That's it!

_______________________________________________
RAI mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rai

---

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Thu, 8 Nov 2007 20:47:32 -0600

Do you believe that the call/session flows are normative or informative?

RFC 3665 call/session flows are very good illustrative examples, but do
not really depict real deployments (measured in number of calls). 

And further, RFC 3666 does not interoperate with the PSTN, thereby not a
good example.

Cheers,

Martin

-----Original Message-----
From: Peter Saint-Andre [mailto:[email-masked]] 
Sent: Thursday, November 08, 2007 7:19 PM
To: Brian Stucker
Cc: sip; [email-masked]
Subject: Re: [Sip] RAI-ART Review Comments for
draft-ietf-sip-hitchhikers-guide

Brian Stucker wrote:

<snip/>

Sorry to hijack this thread, but I'd like to second a comment that Mary
Barnes made during the WGLC:

http://www1.ietf.org/mail-archive/web/sip/current/msg20981.html

***

It seems that all the call flow BCPs are missing and I do think those
are really important and should be included in this document.  The only
BCP (type (B) document) listed in this document is 3PCC.  The basic call
flow document (RFC 3665) should be listed in section 3 (Core SIP).  The
PSTN call flows (RFC 3666, BCP 76) should be in PSTN Interworking
section 4. The SIPPING NAT scenarios document should be in the NAT
section 6.  These docs are all icing on the cake IMHO and help to guide
implementers in using all the other docs.

***

I agree that the call flow documents are very useful and that a
reference to them would be a good thing.

Peter

---

From: "Brian Stucker" <[email-masked]>
Date: Fri, 9 Nov 2007 10:50:00 -0600

Callflows: they're such a double-edged sword.

They do a good job of quickly explaining something, but can't cover off
all the vagaries of the spec. They do such a good job, in fact, that
it's not uncommon for implementors to simply implement the
easy-to-understand call flow thinking they've captured all of the
important bits of the underlying specifications; that they never
properly check to see that they've, in fact, actually implemented the
spec correctly at all.

If we're going to include those, then there needs to be a considerable
amount of warning text exhorting the reader to use the callflows as a
study aid for the specifications and not as a substitute.

Regards,
Brian

> From: DOLLY, MARTIN C, ATTLABS [mailto:[email-masked]] 
> Sent: Thursday, November 08, 2007 8:48 PM
> To: Peter Saint-Andre; Stucker, Brian (RICH1:AR00)
> Cc: sip; [email-masked]
> Subject: RE: [Sip] RAI-ART Review Comments for 
> RFC 3665 call/session flows are very good illustrative 
> examples, but do not really depict real deployments (measured 
> in number of calls). 
> 
> And further, RFC 3666 does not interoperate with the PSTN, 
> thereby not a good example.
> 
> Cheers,
> 
> Martin
> 
> 
> 
> Sorry to hijack this thread, but I'd like to second a comment 
> that Mary Barnes made during the WGLC:
> 
> It seems that all the call flow BCPs are missing and I do 
> think those are really important and should be included in 
> this document.  The only BCP (type (B) document) listed in 
> this document is 3PCC.  The basic call flow document (RFC 
> 3665) should be listed in section 3 (Core SIP).  The PSTN 
> call flows (RFC 3666, BCP 76) should be in PSTN Interworking 
> section 4. The SIPPING NAT scenarios document should be in 
> the NAT section 6.  These docs are all icing on the cake IMHO 
> and help to guide implementers in using all the other docs.
> 
> ***
> 
> I agree that the call flow documents are very useful and that 
> a reference to them would be a good thing.
> 
> Peter
>

---

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Fri, 9 Nov 2007 11:06:59 -0600

Brian,

I agree.

Martin 

-----Original Message-----
From: Brian Stucker [mailto:[email-masked]] 
Sent: Friday, November 09, 2007 11:50 AM
To: DOLLY, MARTIN C, ATTLABS; Peter Saint-Andre
Cc: sip; [email-masked]
Subject: RE: [Sip] RAI-ART Review Comments for

Regards,
Brian

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 09 Nov 2007 18:13:46 +0000

So do I. People interpreting call flows as definitive have caused us
lots of grief in the past.

John 

> Sent: 09 November 2007 17:07
> To: Brian Stucker; Peter Saint-Andre
> Cc: sip; [email-masked]
> Subject: [RAI] RE: [Sip] RAI-ART Review Comments 
> fordraft-ietf-sip-hitchhikers-guide
> 
> Brian,
> 
> I agree.
> 
> Martin 
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 14 Nov 2007 01:18:11 -0500

Thanks for the detailed review. Responses below:

> not intended to be exhaustive or confer any special status over

Actually this is not true. The next section provides a concrete criteria 
for inclusion. This is a criteria that was discussed on the mailer and 
in meetings. The idea is NOT to have, on a doc by doc basis, discussion 
and consensus on whether to include it.

I changed the wording in the last sentence to "It is an informational 
document, meant to guide newcomers,
implementors and deployers to the many of the specifications
associated with SIP."

> become RFCs (I think this was already discussed somewhat on the RAI

I'll add the warning per Keiths comment. I'm not sure that the web links 
bring any value in an era of Google.

> disregard or lack of visibility of the IANA registration process to

This document isn't meant to be the cure for the interop problems of 
SIP. Its scope is to help people understand what specs form "SIP" and 
what they are for. Thats it. That includes registry references. I am 
going to stick hard to the original scope of this document.

> that people don't skip over that material would be good as well.

I disagree with this. I think the IETF's view of what is an 'update' vs. 
an 'extension' is academic for implementors. I think its worth noting so 
there is no surprise, but I don't want this long list of things which 
"are" 3261 when they each have their own RFC number.

Essential corrections is already listed in the core specifications list 
so I am not worried about it being missed.

I will mention in the sections on 3853, 4320, 4916 that they formally 
update 3261.

> that arise in implementations?

That document is informational. It is meant as a clarification to 
rfc3264. The scope of the hitchhikers document doesn't include such 
documents. If you want to further expand the scope to include documents 
that are informational clarifications, please post a note to sip and 
raise this as proposed scope change for hitchhikers. As I said above 
though, I disagree with any proposed increases in scope beyond our 
original agreed set.

> provides the security in contrast to a mechanism like RFC-4474. 

Changed to "network asserted".

> traverse (ALGs and SBCs aside).

I removed and added a pointer to the section.

> the RFC is much newer (and has more complicated requirements) than

Well, we'll be revising the hitchhikers guide every year or so. Should 
this statement no longer be true we can adjust it.

> to highlight that newcomers should ignore what's in RFC3261.

OK.

> then why are we including it in the guide? 

Because they are extensions and that is the scope of hitchhikers.

> endpoints are obviated from the network.

OK.

> to be the case, so just a sentence or two should suffice to warn the

Added:

Early media
   is a complex topic, and this specification does not fully address
   the problems associated with it.

> solve all of the early media issues.

Mentioned.

> Shouldn't we have an entry in this section for RFC3966 to cover tel

No. It does not meet the defined scope:

* SIP extensions
* MIME objects just for SIP
* SDP stuff just for SIP

> PSTN interworking and is more than mildly deployed depending upon the

Agree its not just there; the draft says that was the origin of it, and 
that it is 'most common' in PSTN interworking devices. I believe this to 
be true. I'll change "mild" to "moderate".

> call out that it can be used to convey mid-call information as well.

changed to:

<t hangText="RFC 3311, The SIP UPDATE Method (S):">RFC 3311 <xref
target="RFC3311"/> defines the UPDATE method for SIP. This method is
meant as a means for updating session information prior to the
completion of the initial INVITE transaction. It can also be used to
   update other information, such as the identity of the participant
   <xref target="RFC4916"/>,
   without involving an updated offer/answer exchange. It was developed
initially to support RFC 3312 <xref target="RFC3312"/> but has found
   other uses.
</t>

> deployment and applicability.

I assume you mean the 3gpp route set validation based on service route? 
Not sure what else you might mean by "capture route set of a 
registration to know how to route future requests". The route header 
field in client requests is used to route future requests.

In terms of DEPLOYMENT of this, if you mean the 3gpp stuff there is 
little deployment so far so I think my statement remains accurate.

> 	Should probably call out the relationship between this RFC and

ok

> Need to remove duplicate entry for SDP negotiation under PSTN

which duplicate entry?

> RFC4758 is intended for this purpose now (later comment).

Hmm, well I didn't think there had been WG consensus to use 4458 for 
voicemail over 4424 - thats why it got published as informational (and 
indeed it was an individual submission IIRC).

I agree it is more broad but its original target and most common usage 
AFAIK remains voicemail. Suggest:

came to be routed to a particular destination. Its primary application
was in support of voicemail services though it has more broad
   applicability. </t>

> Shouldn't we have an entry in this section for RFC3880, CPL?

No, it doesn't meet the scope of this document:

* SIP extensions
* MIME objects just for SIP
* SDP stuff just for SIP

> reason to have this RFC or ICE in the core specifications section?

The spec says that certain docs get listed in multiple areas for 
convenience.

It appears in the core specs because of the formal definition of core specs:

<t>
The core SIP specifications represent the set of specifications whose
functionality is broadly applicable. An extension is broadly
applicable if it fits into one of the following categories:
</t>

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

Our intention with ICE is that a client should always be using it; the 
majority of deployments involve at least one endpoint that MIGHT have a 
NAT issue, and thus ICE gets used. WHen ICE is used 3605 comes along for 
the ride.

> that OUTBOUND should be considered one as well?

Yes, and it is listed there.

> 	It's used extensively in other SDOs, paricularly wireless.

Well, defined by an SDO is not the same as deployed. But anyway I'll 
remove the statement in this case since its a minor spec in any case.

> This is somewhat important given the low current deployment of KPML.

OK.

> to come up with a BCP implementation.

I added 4896.
3486 doesn't meet the scope of hitchhikers:

* SIP extensions
* MIME objects just for SIP
* SDP stuff just for SIP

> service URI as another important service URI RFC.

added.

> since it's a correction to 3261.

Update noted.
However its not core since SMIME is not used in every call. See above 
for the definition of a core spec. Just because a document updates SIP 
does not make it a core spec.

> RFC4474', or be dropped altogether?

It basically does say that.

> it's needed for their purpose.

I think this is a useful piece of guidance. I know I have answered this 
question many times about whether this feature is needed.

> Shouldn't we perhaps move RFC4796 from section 7 to this section?

Why?

> Providing a pointer off to ECRIT seems useful here.

That scope comment again.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 14 Nov 2007 01:20:38 -0500

The call flow documents do not meet the current criteria defined by 
hitchhikers for inclusion. That criteria is:

    It is very difficult to enumerate the set of SIP specifications.
    This is because there are many protocols that are intimately related
    to SIP and used by nearly all SIP implementations, but are not
    formally SIP extensions.  As such, this document formally defines a
    "SIP specification" as:

    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

    o  Any specification that defines an extension to SDP whose primary
       purpose is to support SIP

    o  Any specification that defines a MIME object whose primary purpose
       is to support SIP

Example call flows do not meet this criteria.

-Jonathan R.

---

From: "Mary Barnes" <[email-masked]>
Date: Wed, 14 Nov 2007 08:48:42 -0600

Jonathan,
  
I honestly think that not having the call flows, which are BCPs, leaves
a huge gap in the document.  And, I think not having them is contrary to
these statements in the hitchiker's guide (from the intro):
   "It is an informational document, meant to guide newcomers,
    implementors and deployers to the SIP suite of specifications."
And  (in the paragraph following the text you extracted): 
   "Best Current Practices are included when they normatively define
mechanisms for
   accomplishing a task."

IMHO, that is the case with all the call flow BCPs, per the basic
definition of BCP in RFC 2026:

   A BCP document is subject to the same basic set of procedures as
   standards track documents and thus is a vehicle by which the IETF
   community can define and ratify the community's best current thinking
   on a statement of principle or on what is believed to be the best way
   to perform some operations or IETF process function.

At a minimum,  basic call flows fits into this category because the ones
in RFC 3261 are not comprehensive. 
If we don't tell newcomers about the call flows in this document, they
will likely miss them, since the whole point of this document is to help
them navigate the specs. It would be okay of the call flows were
referenced in the other documents, since more astute developers would
have the sense to look at referenced docs, as well, many of them are not
referenced. For example, the only document that seems to reference basic
call flows is RFC 4083 (3GPP requirements).  If the reluctance to
include the call flow BCPs is a concern that they no longer reflect
"Best" current practices, then we need to start updating those documents
or we need to obsolete them.  

I also just noticed that one BCP that wasn't mentioned yet was RFC 4579.
It would be difficult to figure out how to put together a SIP based
conferencing implementation based only on the other docs in section 8
(conferencing) without the call flow document.  

Regards,
Mary. 

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Wednesday, November 14, 2007 12:21 AM
To: Peter Saint-Andre
Cc: sip; [email-masked]; Stucker, Brian (RICH1:AR00)
Subject: Re: [Sip] RAI-ART Review Comments for

    o  Any specification that defines a MIME object whose primary
purpose
       is to support SIP

-Jonathan R.

Peter Saint-Andre wrote:
> Brian Stucker wrote:
> 
> <snip/>
> 
> Sorry to hijack this thread, but I'd like to second a comment that 
> Mary Barnes made during the WGLC:
> 
> are really important and should be included in this document.  The 
> only BCP (type (B) document) listed in this document is 3PCC.  The 
> basic call flow document (RFC 3665) should be listed in section 3 
> (Core SIP).  The PSTN call flows (RFC 3666, BCP 76) should be in PSTN 
> Interworking section 4. The SIPPING NAT scenarios document should be 
> in the NAT section 6.  These docs are all icing on the cake IMHO and 
> help to guide implementers in using all the other docs.
> 
> ***
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
[email-masked] for questions on current sip Use
[email-masked] for new developments on the application of sip

---

From: "Henry Sinnreich" <[email-masked]>
Date: Wed, 14 Nov 2007 07:51:31 -0800

I fully agree with Mary and wish we would have similar call flow
examples for SIMPLE as well instead of a guide only. 

The hitch-hikers guides without references to (1) call flow examples and
yes, (2) OS code seems like a band-aid instead of the real thing.

Call flow examples and OS code are IMHO the only proof the guides are
anchored in reality. Example: IETF meetings use Jabber instead of SIMPLE
and no guide will change this fact.

This makes me question the usefulness of these hitchhikers guides for
SIP and SIMPLE, unless they have references to call flow examples and OS
code or similar. 

I suggest both guides for SIP and SIMPLE to be re-edited with such
references.

Thanks, Henry

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]] 
Sent: Wednesday, November 14, 2007 6:49 AM
To: Jonathan Rosenberg; Peter Saint-Andre
Cc: sip; [email-masked]
Subject: [RAI] RE: [Sip] RAI-ART Review Comments

Jonathan,

Regards,
Mary. 

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Wednesday, November 14, 2007 12:21 AM
To: Peter Saint-Andre
Cc: sip; [email-masked]; Stucker, Brian (RICH1:AR00)
Subject: Re: [Sip] RAI-ART Review Comments for

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 14 Nov 2007 14:10:18 -0500

Mary,

Don't get me wrong - I'm not passing judgement on the value of the call 
flow specs, or on any other spec for that matter. I'm just trying to 
keep the scope of this document to a point where there is an objective 
definition we can agree to which defines the contents of the document.

The current definition focuses squarely on protocol specs - extensions 
and object specs and the like. Those collected together define the 
functionality provided by SIP. I do agree that a BCP can, for all 
intents and purpsoes, be thought of as a protocol spec in that it 
normatively defines behavior. We have a BCP in there now (3pcc).

Whats interesting is that the call flow specs (3665, 3666) are BCP, but 
frankly I'm not sure why. RFC 3665 for example contains the definitions 
of RFC 2119 terms, but never once uses any of them. To me, a BCP is a 
BCP and not informational because it has such terms - it describes 
behavior in some way.

We could choose to expand the definition of the scope of the hitchhikers 
guide to include example call flow documents, whether they be 
informational or BCP. That would throw in a few more (torture tests for 
example). The main question I would ask is whether we view those kinds 
of informational documents as different from ones like RFC 5057 
(multiple dialog usage) which, I would argue, is closer to what  BCP 
ought to be, in terms of defining behaviors explicitly that are 
non-obvious or unspecified in the base specs.

-Jonathan R.

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 15 Nov 2007 00:20:38 -0600

Thanks for the updates. Replies below.

Regards,
Brian 

> Sent: Wednesday, November 14, 2007 12:18 AM
> To: Stucker, Brian (RICH1:AR00)
> Cc: [email-masked]; sip
> Subject: Re: RAI-ART Review Comments for 
> > document. Apologies for the probable repeats in here from list 
> > comments, I was not able to try to correlate my comments 
> with others 
> > on the various reflectors.
> > 
> > May want to change "meant to guide newcomers, implementors and 
> > deployers to the SIP suite of specifications" since many of the 
> > documents are not predicated upon SIP itself. For example, 
> RFC-4566, 
> > 3388, 3264. Also, I don't think we want to imply that this 
> document is 
> > exhaustive. Perhaps "It is an information document, meant 
> to introduce 
> > newcomers, implementors and deployers to many of the important IETF 
> > specifications associated with SIP. Specifications 
> referenced by this 
> > document were chosen based on working group consensus and the list 
> > presented here is not intended to be exhaustive or confer 
> any special 
> > status over documents not included."
> 
> Actually this is not true. The next section provides a 
> concrete criteria for inclusion. This is a criteria that was 
> discussed on the mailer and in meetings. The idea is NOT to 
> have, on a doc by doc basis, discussion and consensus on 
> whether to include it.
> 
> I changed the wording in the last sentence to "It is an 
> informational document, meant to guide newcomers, 

Fair enough.

> 
> > 
> > Might also want to include some pointers to the relevant WG 
> webpages 
> > to give newcomers a place to go for further information. As well as 
> > include some boilerplate about the dangers of implementing I-D's 
> > before they become RFCs (I think this was already discussed 
> somewhat 
> > on the RAI mailing list).
> 
> I'll add the warning per Keiths comment. I'm not sure that 
> the web links bring any value in an era of Google.

Fair enough.

> going to stick hard to the original scope of this document.

Not the cure, certainly, but if the IANA registration process for SIP
extensions is considered out of scope, then perhaps a pointer to 4485
somewhere instead? Seems mostly harmless. :)

> I will mention in the sections on 3853, 4320, 4916 that they formally 

Thanks.

> though, I disagree with any proposed increases in scope beyond our 

So you'd rather have a document that formally lists which other unclear
documents comprise the SIP specification as an aid to the implementor
for a core function of the protocol? 

Informational or not, we have real debates at the meetings around what
is correct and what is not correct in terms of how offer/answer is used
and that is captured in the offer/answer draft. 

I would agree that informational documents that do not clarify other
normative statements are out of scope, but that does not seem to be the
case here. The offer/answer draft isn't trying to make changes to
mechanism but to clarify unclear points of the existing normative
language so that people can implement the existing mechanisms properly.
It's informational only in that it does not need to be normative to do
the job. It is clearly not the same type of informative documents as
some others, or even, arguably, some of the BCP documents.

I'd argue that including a normative document that nobody uses is of
equal or lesser utility in this case.

Is this really then out of scope? Since this post is cross-posted to the
SIP list, please consider the note posted.

One thing I noticed while going back through the document during this
reply is that you include a reference to RFC-4091 which is obsoleted by
ICE. Don't know how you want to handle that one.

> Changed to "network asserted".

Thanks.

> I removed and added a pointer to the section.

Thanks.

> this statement no longer be true we can adjust it.

Fair enough.

> > to highlight that newcomers should ignore what's in RFC3261.

Thanks.

> > endpoints are obviated from the network.

Thanks.

>    the problems associated with it.

Perfect.

> > solve all of the early media issues.

Thanks.

> * MIME objects just for SIP

But TEL URIs are mentioned in RFC-3261, section 19.1.6. It's not
explicitly an extension to SIP but it's used an awful lot with SIP.
Still out of scope?

> be true. I'll change "mild" to "moderate".

Fine. No need to split hairs on this one, just highlighting the point.
Thanks.

> initially to support RFC 3312 <xref target="RFC3312"/> but has found

Excellent, thanks.

> little deployment so far so I think my statement remains accurate.

Yes. Upon further reflection, I'll withdraw the comment.

> > Need to remove duplicate entry for SDP negotiation under PSTN

Sorry, you are correct. I misread reference to [105] to be duplicate to
later reference to [106]. Nevermind.

> was in support of voicemail services though it has more broad

Sounds fine.

> * MIME objects just for SIP

Ok. Fair enough. I'm sure it'll come up in a BLISS document anyhow.

> NAT issue, and thus ICE gets used. WHen ICE is used 3605 

Fair enough.

> remove the statement in this case since its a minor spec in any case.

The text used the term 'usage' so I didn't know precisely what you meant
(usage by other specifications vs. deployment). Just trying to capture
as much as we can, I agree it's a minor spec.

> * MIME objects just for SIP

Huh? How is 3486 not an extension to SIP? It defines a URI parameter for
the SIP/SIPS URI scheme along with other normative behavior specifically
for SIP (it's even in the title).

> does not make it a core spec.

Fair enough.

> It basically does say that.

Ok. Agree.

> question many times about whether this feature is needed.

Ok. I hadn't even heard that question, but if it's being asked, then I'm
ok with the reader figuring it out for themselves either way.

Section 16: 

16.  Instant Messaging, Presence and Multimedia

   SIP provides extensions for instant messaging, presence, and
   multimedia.

Entry for RFC4796:

  RFC 4796, The SDP (Session Description Protocol) Content Attribute
   (S):  RFC 4796 [94] defines an SDP attribute for describing the
      purpose of a media stream.  

Seems more related to multimedia than that it's a minor extension
although I don't feel strongly either way. If you want to leave it
alone, I'm ok with that. Was only a suggestion.

> That scope comment again.

Ok.