Subject: [Sip] Comments on bis-07.

From: "Jo Hornsby" <[email-masked]>
Date: Fri, 15 Feb 2002 03:46:29 -0000

Hi.

Okay, so first-off, a number of points to note:

 o All comments are initially based on the .txt
   version of the Draft.  If I was supposed to look
   at the PDF, or PS, then I do not want to know.
   I will have to kill myself.
 o I think that this has already been mentioned on
   the list, but a lot of the Reference numbers
   (i.e., the "[xx]"s) seem screwed.
 o I also realize that PRACK is being ripped out.
   However, I have mentioned issues anyway, in case
   some of the text will be moved verbatim.
 o I have tried to trap each occurrence of the first
   use of a particular term.  This may well be
   bogus, but I don't want to have to repeat this
   paragraph in each instance, so please forgive me
   if I am just being silly.
 o There are a number of places where there seem
   to be more blank lines than are necessary.  I
   have ignored these since it gives me a comeback
   for when someone / everyone accuses me of being
   too picky.  I will note occurrences on a later
   parse if so desired....
 o A repeated error seemed to be that Call-IDs in
   example messages were missing the @FQDN.  I
   realize that this is not illegal, but is it what
   was intended?
 o I have not noted some inconsistent terminology.
   I will write a followup email about that.
   Hopefully.

And without further ado:

 * 20:
   s/the users/a user's/

 * 22:
   s/ontop/on top/

 * 300:
   Not sure to what "services" applies here.
   Should this read "applications"?

 * 315:
   First use of "URI".

 * 368:
   First use of "HTTP".

 * 369:
   s/"Method"/"method"/ ?

 * 399:
   First use of "IP". &:)

 * 402:
   Perhaps add "within a dialog" after "for each
   new request"?

 * 404:
   First use of "FQDN".

 * 406:
   Perhaps remove "for this dialog", since Contact
   now has "global" scope, right?

 * 418:
   First use of "DHCP".

 * 424:
   Also mention Vias here (since these days they
   most important in correlating responses)?

 * 431:
   s/Atlanta.com/atlanta.com/

 * 441:
   Unfortunately, since the proxies returned 100s,
   they have to retain state.  (But the inaccuracy
   probably doesn't particularly hurt.)

 * 469:
   Broken "Call- ID".

 * 484:
   I find the "is sent by Alice to Bob" slightly
   confusing, as it makes me think that Alice has
   been proactive in some way.  Maybe "Alice's UA
   to Bob's UA"?  Although this might be the first
   occurrence of UA. &:)

 * 488:
   Remove "and is the end of the transaction"?
   Since really it's two transactions, and
   explaining otherwise could get hairy, I worried.

 * 507:
   Broken "non- INVITE".

 * 524:
   Space between "location service" and "," (but
   not in the PDF; hmmm... is this because of
   the italicisiness, or something; I'll keep
   noting, anyway, just in case).

 * 532:
   How about "a set of zero or more URIs that tell"
   instead of "a translated URI that tells"?

 * 537:
   Change beginning of line to "on a request-by-
   request _basis, by a_ challenge/response
   mechanism, or using a"?

 * 563:
   First mention of "UAC".  Perhaps
   s/UAC/user agent client (UAC)/ ?

 * 576:
   Perhaps s/UAS/user agent server (UAS)/ ?

 * 584:
   Perhaps s/UA/user agent (UA)/ ?

 * 619:
   I think it would be helpful if we changed to
   something like "A call stateful proxy is always
   _(transation)_ stateful, but the converse
   is not _necessarily_ true"?

 * 623:
   I don't think that UAC and UAS make much sense
   when talking about a dialog, since their role
   changes over time.  Howsabout
   s/a UAC and UAS/2 UAs/ ?

 * 633 [Uber-nit]:
   Should this be "Home Domain" or "Home domain"?
   Approach is inconsistent in this entire section.

 * 666:
   Space between "sequential search" and "," in .txt.
   Could be the old italics.

 * 671:
   Missing a trailing "."; however, is present in
   the PDF, so could be the old italics.

 * 677:
   Perhaps "...when it generates a new request to
   _one or more of_ the URIs in the Contact"?

 * 679:
   To affirm the notion of logical roles, perhaps
   "A redirect server is a server that generates a
   3xx response to a request"?

 * 697:
   Should this actually be "non-2xx and non-6xx"?
   (I'm not sure.  But it would seem to make sense,
   given the suggested behaviour when parallel
   forking.)

 * 702-703:
   Spaces before commas again in .txt.  Fault of the
   Italics?

 * 706:
   s/was a non-2xx/was a non-2xx to an INVITE/
   perhaps?

 * 735:
   A small point, but perhaps this should be "If
   it receives a request later on, it _may assume_
   the role of a user agent server"?  Since the
   "piece of software" could also be capable of
   functioning as a proxy?

 * 797:
   s/SIP-version/SIP-Version/

 * 852:
   Seems to be an extra space between "field-name"
   and "field-value" (certainly in .txt).

 * 914:
   First mention of "UDP".

 * Section 7.4:
   CANCEL requests / responses cannot contain a
   body, right?  This is probably worth noting
   here.

 * 942:
   I'm not sure what the "Likewise" is pertaining
   to?  Should it read "Like HTTP, however" or
   sommat?

 * 943:
   Missing terminating ".".

 * 950:
   Probably just me, but I'd find "zero or more
   proxy servers" a little clearer than "some number
   of proxy servers".

 * 975:
   s/register/a REGISTER/ ?

 * 978-979, Sentence beginning "Commonly":
   I find this a little confusing, since all
   the methods explicitly mentioned are non-SIP.
   Is there an "other" missing from between
   "some" and "non-SIP"?

 * 988:
   Perhaps s/SIP URI/SIP URI scheme/ ?

 * 997:
   It might be helpful to note that this is only
   an option when the entered string could
   actually reasonably be a tel URL; e.g., it's
   just digits?

 * 1003:
   Since this is the first use, it might be useful
   to explicitly spell out "tag" parameter.

 * 1008:
   "general-header" not good.

 * 1046:
   s/Cseq/CSeq/

 * 1048:
   The "the sequence number value is arbitrary"
   assertion is not true for REGISTER.  Perhaps
   "For non-REGISTER requests, and for requests
   outside of a dialog, the sequence number value
   is arbitrary"?

 * 1065:
   Perhaps s/protocol/protocol name/ and
   s/version/protocol version/ to remove any
   confusion with transport protocol?

 * 1070:
   "to this rule is CANCEL" -> "to this rule is
   CANCELs and ACKs for non-2xx" ?

 * 1081:
   Broken Section Link.

 * 1093:
   Missing trailing "." in .txt.  [Suspect due to
   fixed-width-font.]

 * 1138:
   Seems to me there are other possible events,
   such as no DNS records, ICMP on all attempts,
   yada yada?

 * 1141 [paranoia]:
   Since this talks about treating Nxx as being
   equivalent as N00, do we need to say "this
   doesn't apply where N = 7 / 8 / 9 / 0, kids!"

 * 1153:
   Capitalize "responses" in Section title.

 * 1153:
   Should this read more along the lines of
   "for example, a 301 response"?

 * 1170:
   Why are "network timeouts" mentioned?  I would
   have thought that these came under the umbrella
   of the "Client transaction reporting".

 * 1173:
   Is it worth noting additionally that some
   failures may be recoverable, as indicated by
   the following sections (f.ex., 401)?

 * 1185:
   I think that "<" and ">" need to be escaped.

 * 1196:
   Capitalize "responses" in Section title.

 * 1207:
   Missing a closing ")" after "25.4.14".

 * Section 8.2:
   How mandatory is the order of these steps?  For
   example, I can imagine that a 405 might depend
   on the Request-URI.  Or can this all effectively
   be modelled as virtual proxying within a
   particular piece of software?

 * 1242:
   I think "layer" should be removed.

 * 1248:
   s/those contact addressess/that contact address/

 * 1250:
   s/TU/UAS/

 * 1258:
   No like "general-header".

 * 1262-1264, Sentence beginning "Upon receipt":
   This sentence seems to be superfluous --
   especially in this Section, which is about UAS
   behaviour -- since it is just a repeat of Lines
   1210-1212.

 * 1317:
   Why do we no-longer recommend 1xx for non-INVITE
   (I'm presuming 1xx here includes 100).

 * 1324:
   s/Cseq/CSeq/

 * 1325:
   s/Cseq/CSeq/

 * 1327:
   Delete "in the request".

 * 1359:
   s/URI/URI(s)/

 * 1396:
   s/Required extensions/any unknown option tags
   in Require/ ?

 * 1396:
   s/session/request/

 * 1398:
   Is this sentence implying that a redirect
   server should understand all option tags in
   a Proxy-Require?  If not, then I think its
   presence here is confusing.  (Not that I
   think it shouldn't.  I'm slightly ambivalent
   about this.  But I'll rant later when we
   reach "Proxy-Authenticate".

 * 1405:
   Is "servers" missing from between "CANCEL
   requests to" and "which can take a long time"?

 * 1407:
   s/response/final response/

 * 1409:
   Perhaps change to "CANCEL requests can be
   constructed and sent by both proxies and user
   agent clients", since that's pretty-much
   everything?

 * 1412:
   "Because a stateful proxy can generate its own
   CANCEL, a stateful proxy also respond to a
   CANCEL" -> "A stateful proxy responds to a
   CANCEL," ?  I don't see how the very first bit
   of the sentence is relevant.

 * 1438:
   Use of the word "original" concerns me slightly
   here, since SRV-based failover may have
   occurred?

 * 1477:
   I would have thought that replacing "must"
   with "may be required to" is more appropriate,
   since proxies aren't essential.

 * 1481:
   Space between "location service" and "," in .txt.
   [Probably due to italics.]

 * 1482 [for consistency]:
   s/Biloxi/biloxi/

 * 1482:
   Space between "sip:[email-masked]" and "," in .txt.
   [Probably due to fixed-width-font.]

 * 1483 [for consistency]:
   s/Biloxi/biloxi/

 * 1483:
   Space between "sip:[email-masked]"
   and "," in .txt.  [Probably due to fixed-width-font.]

 * 1484-1485:
   Perhaps replace sentence with "Ultimately, a
   proxy will consult a location service that maps
   a received URI to the user agent(s) at which
   the desired recipient is currently residing."?
   Specifically, the use of "host(s)" and "logged"
   seems a little random.

 * 1497-1499:
   I found the second sentence a little hard to
   parse.  What about:
   "_A_ registrar acts as _the_ front end to the
   location service for a domain, reading and
   writing mappings based on the contents of __
   REGISTER requests."

 * 1539:
   s/contact addresses/the contact address(es)/

 * 1545:
   Perhaps append "for example" to the end of this
   sentence?

 * 1582:
   This sentence would seem to be more appropriate
   for Section 10.2.3?

 * 1587:
   s/to refresh/for refreshing/

 * 1597:
   s/for REGISTER request/to a REGISTER request/

 * 1605:
   s/chicago.com/sip:chicago.com/

 * 1635-1636:
   Since we're talking atomically, I think it would
   be clearer if the text said "meaning that _a
   particular_ REGISTER request is either processed
   completely or not at all"?

 * 1650-1651:
   Having trouble parsing the sentence.  How about
   "For example, a registrar might consult an
   authorization database that maps user names to
   lists of address-of-records for which that user
   has authorization to modify bindings."?
   Hmmm.  Mebbe.

 * 1651:
   s/If not/If the user is not authorized/

 * 1687:
   Did I miss some discussion on why the Call-ID
   is now significant to the registrar?  I don't
   understand why the restriction on the client
   not being able to send a REGISTER until the
   previous one has completed doesn't force the
   necessary ordering.

 * 1694:
   Perhaps add "e.g., because the backend database
   commit failed"?

 * 1701/1702:
   Seems to be an extra space between "etc." and
   "without".

 * 1748:
   Is "Section 13.2.1" the right link here?  It
   doesn't seem to fit with what the rest of the
   paragraph is saying.

 * 1799-1800:
   I think s/remote target/peer/ would be slightly
   clearer here.

 * 1830-1831:
   What if there is no Contact?  There use to be
   the notion of that "CONTACT_SET" boolean.
   Granted, it was a little painful, but it did
   potentially solve the problem with a little
   cooperation from proxies, right?  How about
   just trying the From?  Can it really hurt? &:)

 * 1832:
   s/Cseq/CSeq/

 * 1845:
   Same isse with Contact. &:(

 * 1847:
   s/Cseq/CSeq/

 * 1861: OPEN ISSUE #113:
   I say yes.  Interestingly, the resolution is
   already documented in the Changes Section.

 * 1875:
   s/Cseq/CSeq/

 * 1877:
   s/Cseq/CSeq/

 * 1887:
   I think convention might dictate s/lr/"lr"/

 * 1888:
   s/MUST a Route/MUST add a Route/

 * 1914-1917:
   I'm having trouble understanding these two
   paragraphs.  I think a little clarification
   would be helpful here.  Is the intention that
   each Contact in the 3xx could become the new
   remote target URI?  Maybe I've missed some
   further documentation of the procedure (Section
   13.2.2 didn't really seem to say so much).

 * 1921:
   I think s/UAC/UA/ (both occurrences) would be
   more correct.

 * 1931:
   Should this read "In that case, the UAS _first_
   applies the same processing"?

 * 1950:
   Extra spaces between "request:" and "re-INVITE"
   and "Section" and "14".

 * 1955:
   s/Cseq/CSeq/

 * 1957:
   Small point, but I would have thought that 400
   would have made more sense here, since presumably
   it is the client that has erred.  (Although, I
   might note that this will have to be relaxed
   slightly if OPEN ISSUE #113 is "allowed".)

 * 1960:
   s/SHOULD/MUST/ surely.  Why the lee-way?

 * 1962:
   s/Cseq/CSeq/

 * 1964:
   s/Cseq/CSeq/

 * 1965:
   s/Cseq/CSeq/
   You think I'd have wisened up by now, and just
   suggested a global search-and-replace, eh?  Doh.

 * 1973:
   s/This request is forwarded/This request may be
   forwarded/

 * 2002:
   Extra space between "Section" and "24.1".

 * 2002:
   s/content-types/Content-Types/ perhaps?

 * 2008:
   I might suggest "the UAC core SHOULD generate a
   CANCEL request for the INVITE, as per Section 9".
   Since "original" makes me slightly panicky in
   the face of SRV (and I don't see any ambiguity).

 * 2009:
   s/MAY also find useful/MAY also find it useful/

 * 2022:
   s,PRACK,ACK/PRACK, ?

 * 2041:
   Shouldn't the "[2]" actually be "[1]"?

 * 2047-2048:
   Has there been a relaxation on the support of
   INVITE?  I might suggest: "All user agents MUST
   support all the exchanges listed in the above
   rules, based on their support for PRACK."

 * 2085-2087:
   I think it would be more sensible if these two
   paragraphs were moved into their own section;
   say "non-2xx final responses" or sommat?

 * Sections 13.2 and 13.3:
   One thing I have failed to find, is a treatise on
   the explicit semantics of Allow/Accept[-*], etc.,
   as possible mutators of dialog state?  Is the
   intention that there be no normative text, or
   have I just missed?

 * 2123/2124:
   I would have thought that a 408 was more
   appropriate?  But small Point.

 * 2146:
   Extra space between "Section" and "8.2.6".

 * 2168:
   "a Contact header field containing URIs of new
   addresses to be tried" -> "a Contact header field
   containing one or more URIs to try" (to account
   for the singular case)?

 * 2248:
   s/the same as for an INVITE/the same as for the
   initial INVITE/

 * 2254:
   Again, I would have thought that a 400 was more
   appropriate, since the client is the one that
   messed up.

 * 2260/2262:
   I could find no definition what it means to be
   the "owner" of a Call-ID.

 * 2288:
   s/unbound/unbounded/

 * 2327-2331:
   Surely just about any response to a BYE means
   that the dialog is down; more importantly, how
   useful is the response to a BYE in general,
   beyond halting request retransmission?  I'm not
   sure why these cases are explicitly mentioned.

 * 2344:
   Could there not be other pending requests, such
   as OPTIONS?  Or is this working on the basis
   that all other requests don't really pend as such.

 * 2375:
   Errr...I'm not sure how a CANCEL could be sent;
   or is it assumed that if one were (for whatever
   inexplicably good reason), the CANCEL would be
   sent statefully?

 * 2381:
   s/Server/server/
   s/Client/client/
   s/Transactions/transactions/

 * 2394-2397:
   This list is malformatted in the .txt.

 * 2436:
   Surely s/MAY/SHOULD/ or even s/MAY/MUST/ since
   why bother doing LD otherwise?

 * 2464:
   Broken Section Link.

 * 2507:
   Does this forbid retries to the same destination
   with a different request (i.e., with different
   headers, or whatever)?  This could be a shame,
   since it might get in the way of proxies acting
   oppurtunistically; say, with "Require".

 * 2521-2524:
   I find the distinction between when to return a
   404 and when to return a 480 too subtle, and
   since we are talking MUSTs, I feel it needs to
   be relaxed a little.  (Since location services
   are abstract, I see it as very difficult to
   determine which case should apply.)  Why not
   just RECOMMEND a 404 in both cases?  (I wouldn't
   want a MUST on 404, since may be the location
   service goes to pants, in which case 504, or
   similar may be more appropriate.)

 * 2575:
   I think consistency would have this as
   "(see Item 3 of Section 16.3)".

 * 2588:
   s/Section/Sections/

 * 2593:
   s/must/MUST/

 * 2610-2618:
   Is there any reason this little bit cannot be
   moved up, say to just before 2485?  That is
   because this text basically results in the
   destination set (although constrained to being
   of unit size) being completely trounced.
   Moving this to just before 2485 sits quite
   nicely with the check in 2479; well, with me,
   anyway.

 * 2666:
   s/record-route/Record-Route/ ?

 * 2685:
   In any case, should not be "Section 5", and if
   the 2610-2618 move is undertaken, cannot even
   be "Step 5".  Oh dear.

 * 2695:
   I would think that it should not be 408, and
   should instead depend on the result reported by
   the transaction layer (say 404 if no DNS records;
   or 480 if DNS records, but no servers responded;
   or 502 if ICMP; ...).  I guess this is generic
   to client transaction behaviour, however.

 * 2705:
   I don't like this MUST.  Smells like a DoS hole
   to me.  (I, as naughtyJo, could forge a response
   with a whole lotta Vias in it.)

 * 2720:
   s/forward/Forward/

 * 2721:
   s/generate/Generate/

 * 2739:
   Should be Section 9?

 * 2740:
   Spurious ";".

 * Section 16.6, Step 4:
   There may be other cases where a proxy is able
   to be clever and try a request again, and thus
   the response should not be added to the context.
   Obviously, this does require the UAS to be well
   keen, and look at seeming Request Merges very
   carefully; however, it doesn't seem unreasonable
   that an extension could employ a wickedclever
   use of this.

 * 2768:
   s/all pending transactions/all pending client
   transactions/ (for clerity).

 * 2768:
   Should be Section 9?

 * 2780:
   Consider "Step 4" instead?

 * 2781-2782:
   Consider "Steps 7 and 8" instead?

 * 2784:
   s/exactly one non-2xx response/exactly one non-2xx
   final response/

 * 2789:
   Does there need to be the addition of something
   along the lines of "...and there are no destinations
   pending in the destination set and no hope for
   further population of the destination set?"  Just
   to be explicit about results triggering further
   proxy attempts (with SIP Servlets, f.ex.).

 * 2792:
   Hmmm....  408 doesn't look right to me.  Finally,
   I find somewhere where I'd really be happy with
   a 480! &:)

 * 2794:
   Isn't 6xx still considered better than 3xx,4xx,
   5xx?  Also, I would prefer a SHOULD for the
   lowest class here, since it enables a proxy to
   be a little more clever.  It may get a 3xx to
   what it knows is voicemail, for instance, but
   know somehow that voicemail is no good to the
   client, so return a 486.  I'm certainly no
   expert on CPL, but it seems to me that it would
   be possible to violate this MUST with the
   use of "reject".

 * 2802/2803:
   Again, consider "Steps 7 and 8" instead?

 * 2811-2816:
   I think it would be nice if the notion of this
   "virtual UAS" was opened up a little to
   explicitly mention how it could be used to
   generate candidate final responses.  Coupled
   with me above rant on 2794, this nicely
   draws the story together (and gives a reasonable
   model for CPL to work with).

 * 2862/2863:
   Again, consider "Steps 7 and 8"?

 * 2892-2893:
   I would have thought we could do better than
   this; in particular, shouldn't it be the
   transaction layer that is reporting errors?
   (Okay, not if stateless, but things get really
   icky when a stateless proxy results in an
   ICMP, for example.)  I would hope that we can
   come to an agreement of the set of errors that
   a client transaction (or set; I'm slightly
   confused to the distinction when failing-over
   via DNS records) can report, and the semantics
   of these within the SIP status code space.

 * 2905-2910:
   I think there may be a slight race here, due
   to the case when a server transaction for the
   request being cancelled has been created, but
   the response context has not.  (Of course,
   that does depend on whether this spec is
   threaded or not...)  Why not simply have the
   text search for an associated server transaction
   (in particular, the beginning of Section 9.2
   appears generic to any stateful server, anyway),
   and then some notion of communication of the
   CANCEL action to the proxy core, such that it
   can CANCEL any pending client transactions,
   and do whatever else, as appropriate?

 * 2910:
   In any case, this should be Section 9.

 * 2912:
   Is the word "statelessly" missing after
   "CANCEL request"?  And again, I think I'd
   rather a SHOULD, since I'm suspicious that
   there could be some attack potential here.

 * 2934:
   I'm not sure where the notion of a "random
   number generator" comes from.

 * 2935:
   s/Section 16.5 bullet 3/Item 3 of Section 16.5/

 * Section 16:
   I think I might have come up with a slightly
   nasty case with a stateless proxy, that I
   cannot see is forbidden.  Although it does
   look as if the proxy destination is fixed to
   be the same for a particular request, I
   cannot see anything forbidding inconsistent
   header addition / modification.  In partiular,
   this opens up a hole where a stateless proxy
   can append a different Route set to retx of
   a request.  May be I'm missing something here,
   and thus wrong about this; however, if not,
   I think this hole needs to be filled.

 * 3065:
   I thinking that s/gateway/P1/ would be clearer.

 * 3088:
   Space between "13.3.1.4)" and ",".

 * 3102/3103:
   "that server transaction" -- I'm not sure to
   what "that" is pertaining.

 * 3104-3106:
   I would propose changing the sentence to
   "Additionally, in the case of an INVITE request,
   the client transaction is responsible for
   generating any ACKs to non-2xx final responses."
   [I was confused by the "that includes" on line
   3105.]

 * 3132:
   s/INVITE request/INVITE requests/

 * 3176:
   Bunchup between '"calling"' and "state".

 * 3222-3223: Sentence beginning "The ACK request"
   I think this sentence should be removed, since
   its effectively repeated in the next paragraph.

 * 3269:
   I don't quite follow the "and it represents the
   amount of time a non-INVITE server transaction
   will take to respond to a request".  How is that?
   Is it more "and it represents the maximum amount
   of time that a non-INVITE server transaction
   _SHOULD_ take to respond to a request"?  It's
   fair enough that some figure is put down; I
   think it's the "will" that is bothering me.

 * 3290-3291:
   I don't see the need for this with non-INVITE;
   in any case, the text is buggy since it is
   explicitly addressing INVITE.

 * Figure 6:
   For consistency, I think that the topmost text
   should be "Request from TU".

 * 3295-3299:
   This matching logic doesn't sit quite right with
   me.  My understanding is that both conditions
   would have to be true for there to be a match.
   Therefore, I would suggest s/under/by meeting/
   on Line 3296; s/First, if the/First, the/ on
   Line 3296; s/Second, if the/Second, the/ on
   Line 3298; d/The method is/These conditions are/

 * 3329:
   And now I get overly purist.
   Really, in the case of a proxy, I don't think
   that the 1xxs it forwards should be retx upon
   receipt of a request retransmission.  However,
   it would be difficult to describe which response
   to retx here in a generic fashion.

 * 3332:
   s/Response/response/

 * 3348:
   Space in "non- INVITE".

 * Figure 8:
   In the rightmost line, labelled "200-699 from TU",
   the join to the "Completed" box is missing a "<".

 * 3394-3396:
   Am I right in thinking that a possible attack
   was identified at the 52nd IETF with the new
   approach to transaction ID?  I'm having
   difficulty coming up with anything terrible, but
   I guess if an attacker was capable of forging
   source address, and could guess branch IDs,
   it could cause a downstream server to see a
   particular client's request as a retransmission.
   I'm not sure that this is worth mentioning.

 * 3422:
   First use of "ICMP".

 * 3422:
   First use of "SRV".

 * 3475:
   "While this" seems to be missing from .txt.

 * 3478: 
   "If the UAS is unwilling to do so, it MUST reject
   the" seems to be missing from .txt.

 * 3485:
   s/Responses/responses/

 * 3491:
   Extra space between "100rel" and "," in .txt.
   [Fault of fixed-width-font?]

 * 3494:
   Extra space between "100rel" and "," in .txt.
   [Fault of fixed-width-font?]

 * 3515:
   Again, this seems more like a client error, so
   shouldn't it be a 4xx instead of a 5xx.

 * 3535:
   Extra space between "100rel" and "," in .txt.
   [Fault of fixed-width-font?]

 * 3562:
   First use of "TLS".

 * 3563:
   First use of "SCTP".

 * 3575:
   Extra closing ")".

 * 3581:
   I'm not sure what "that" is.

 * 3586:
   First use of "TTL".
 
 * 3587:
   First use of "MTU".

 * 3584-3600:
   As a suggestion, perhaps this could be put into
   a small Subsection on UDP and TCP, since it's
   very oriented towards these transports.

 * 3645:
   For consistency, I would think "parameter"
   instead of "attribute", on both counts.

 * 3655:
   s/the server transaction/a server transaction/

 * 3671:
   First use of "SSL" (is this perhaps a mistake,
   anyway?).

 * 3718/3719:
   401 being used with a redirect server.
   Hmmm....  I guess that I never read the
   authentication Section before (this would seem
   to read roughly the same as 2543).  Anyway,
   it's probably just me being cl00ful, but I
   would have thought that you would use a 407
   for a redirect server, because it's not
   actually the server you're trying to reach?
   Anyway, it really is but a small thing.

 * 3737:
   Extra space between "WWW-Authenticate:" and
   "Digest".

 * 3741:
   Should this be s/UACs/UASs/ ?  Or perhaps just
   UAs?

 * 3806:
   Should this read "MUST increment the CSeq header
   field _if reusing the same Call-ID_ as it",
   since a UAC is free to pick a new Call-ID out
   of thin air?

 * 3811:
   s/UAS/proxy/

 * 3862-3864:
   This paragraph might be better in Step 7 of
   Section 16.6?

 * 3880:
   Section number has gone a little funny in PDF?

 * 3881:
   s,HTTP 1.1,HTTP/1.1,

 * 4002:
   "." missing from end of paragraph.

 * 4017:
   Gratuitous Bracket Application.

 * 4035:
   s/All/Any/ ?

 * 4036:
   Paragraph ends abruptly with "with the" in .txt.

 * 4048:
   Some odd quoting of "inner".

 * 4324:
   First use of "STMP".

 * 4364:
   Perhaps remove "and that".

 * 4396:
   s/UACs/UASs/

 * 4398:
   Would this be more correct as "Digest-based
   authentication"?

 * 4405:
   Remove the "an" before "S/MIME"?

 * 4424:
   Some of the text on this line in the PDF is
   missing from the .txt.

 * 4432/4433:
   This should be 401 (Unauthorized), right?

 * 4460:
   Just a quick query (this is probably more for my
   understanding than anything else): if Alice's
   UA had reused the TLS connection to the "local
   outbound proxy", then surely credentials are
   not really necessary when sending the INVITE.
   Or is it because paranoia says that such
   associations should be timed-out (because Alice
   may have left her UA "logged-in")?

 * 4465/4466:
   Again text gone missing.  In PDF, not in .txt.

 * 4471:
   Again text gone missing.  In PDF, not in .txt.

 * 4477:
   Missing "'biloxi.com'.".

 * 4501/4502:
   Text lossage (in PDF; not in .txt).

 * 4506:
   Text lossage (in PDF; not in .txt).

 * 4540:
   Would insertion of "thus" before "behaving" make
   sense?

 * 4564:
   Would insertion of "a" before "prevalent" make
   sense?

 * 4583-4588:
   Is there some conflict in this paragraph; in
   particular, it alks about a UA being registered
   as the sole contact address, and then mentions
   that a likely failure case is when forking
   occurs.  Maybe if instead of "sole contact
   address", it read "one of the contact addresses"
   (Lines 4585/6).

 * 4680/4681:
   Surely just "Section 8.1.1.1" is more consistent.
   But I am not sure that this is the actually
   desired Section, anyway?

 * Table 1:
   Well, I guess some of the defaults may be
   disappearing from here (port:5060; transport=udp)?

 * Table 1 "heading":
   I find this a little difficult to read.  How about
   "Use and default values of SIP URI components
   in headers, the Request-URI, and out-of-band
   links"?  (Okay, so it's not much better.  I do
   find "references" a little oblique.)

 * 4719:
   I find the ""%" HEX HEX" a little confusing.
   Couldn't the outer "s be dropped?  Also, should
   this actually be "HEXDIGIT"?

 * 4720-4724:
   There's something very odd going on with these
   two paragraphs in the .txt. version.

 * 4761:
   ""%" HEX HEX" again.

 * 4764:
   Well, I guess the bit about 5060 will be going?

 * 4776:
   Broken Section Link.

 * 4778/4779:
   Won't match if new comparison rules.

 * 4785:
   The priority header seems to have gone missing
   in the .txt.

 * 4809:
   To aid clarity, I would suggest replacing
   "request" with "desire".

 * 4813:
   Should this read "SHOULD NOT"?  Otherwise, I
   really don't follow.

 * 4830:
   "headerRequire"?  Enough said.

 * 4873:
   Missing ")" after "24.29".

 * 4880:
   s/host name/domain name/

 * 4926:
   s,servers,clients/servers,

 * 4928:
   s,servers,clients/servers,

 * 4939,4941:
   I am not sure what "not applicable" translates
   to in the table.

 * Tables 2 and 3:
   - Accept/R
     INV: Should be "o". [Section 13.2.1]
   - Accept/2xx
     INV: Should be "o". [Section 13.3.1.4]
   - Accept/415
     BYE, INV, OPT, REG, PRA: Should all be "m".
     [Section 8.2.3]
   - Accept-Encoding/R
     INV: Should be "o". [Could not find any
          normative text about this.]
   - Accept-Encding/2xx
     INV: Should be "o". [Could not find any
          normative text about this.]
   - Accept-Language/R
     INV: Should be "o". [Could not find any
          normative text about this.]
   - Accept-Language/2xx
     INV: Should be "o". [Could not find any
          normative text about this.]
   - Allow/R
     ACK: For consistency, I would say that this
          should be "-".  (None of the "Accept"s
          are allowed, for instance.)
   - Allow/{R,2xx,r,405}
     CAN: To keep CANCEL as clean as possible
          (seeing as hop-by-hop an all), I would
          think that these all be "-".
   - Error-Info/300-699
     CAN: Again, I don't see how this could be
          useful.
   - MIME-Version
     CAN: Since I don't think that CANCEL can
          realistically have a body, does this
          header make any sense?
   - Proxy-Authenticate/407:
     CAN: Cannot be challenged, therefore should
          be "-".
   - Proxy-Authorization/R
     CAN: Hop-by-hop, therefore, should be "-".
   - Record-Route
     s/2xx,401,484/2xx/
   - Record-Route/{R,2xx}
     CAN: Makes no sense to be able to R-R a
          CANCEL; should be "-".
   - Retry-After/[all]
     CAN: Makes no sense for CANCEL; should be
          "-".
   - Route
     I think should be "acr" under "proxy".
     ACK, BYE, CAN, INV, OPT, REG, PRA: Should all
                                        be "o".
   - RSeq/1xx
     Should only be "o" under INV, since 18.1
     specifies that PRACK is only for 1xxs to
     INVITEs.
   - Supported/R
     INV: Should be "m*". [Section 13.2.1]
     CAN: Should be "-".
   - Supported/2xx
     INV: Should be "m*". [Section 13.3.1.4]
     CAN: Should be "-".
   - {Unsupported,Warning,WWW-Authenticated}
     CAN: Should all be "-".

 * 4986:
   Too many "w"s! &:)

 * 5006/7
   Random Line Break.

 * 5011:
   Probably me being a cl00bie again, but what is
   the motivation for this sentence?

 * 5018:
   Disjointed "case-sensitive".

 * 5070:
   Random Line Break.

 * 5076:
   s/handling-parm/handling-param/

 * 5080/1:
   This paragraph conflicts with 5070-2.

 * 5171:
   Not entirely sure how Section 7.3.1 is
   particularly relevant.

 * 5195/6:
   Perhaps this paragraph should be removed.
   Insertion is already a MUST, as per 8.1.1.6
   and Step 4 of 16.5, right?

 * 5200:
   s/to a registrar/of a registrar/ ?

 * 5263:
   s/The Record-Route/The Record-Route header/

 * 5263:
   s/session/dialog/ ?

 * 5267/8:
   It'd probably be nice if these were updated to
   look like they have been created by bleeding-edge.

 * 5275:
   Again, not sure how relevant 7.3.1 is.

 * Section 24.34:
   Table 3 also lists: 413, 480, 486, 500.

 * 5300:
   s/The Route/The Route header/

 * 5367:
   I think this sentence would be a little clearer
   if "and, if not the default port number, the
   port number" were replaced with "and possibly
   the port number".

 * 5368:
   Mentioning "branch" here seems a little
   throwaway, since it is grouped with the
   network-related parameters, and also, "branch
   ID" was mentioned in the previous-but-one
   paragraph; perhaps remove?

 * Section 24.44:
   I think this Section could be a little better
   organized by moving 5372/3 to just above
   5382/3; by moving 5376 above 5374/5; and by
   making one of 5374/5 use compact form (since
   all other Sections seem to give a "compact
   form" example).

 * 5425:
   I read this as saying that the examples
   illustrate new "warn-code"s; however, I can
   only see 301 and 307?

 * 5443:
   Remove "or proxy".

 * 5446:
   Do we need to add a "(typically)" before
   "transmitted reliably"?

 * 5456:
   Remove "proxy", since only UASs can generate
   non-100 1xxs of their own.

 * 5459:
   s/callee/server/ ?

 * 5541:
   s/section 22 and 20.3/Sections 22 and 20.3/

 * 5587:
   s/host/server/

 * 5595:
   How about replacing this whole sentence with
   "The server has detected a loop (Step 3 of Section
   16.3), or a merge (Section 8.2.2.2).

 * 5630:
   s/INVITE/request/ ?

 * 5660:
   Perhaps s/attempt to forward the request/try/ ?

 * 5697:
   s/INVITE/request/ ?

 * 5939:
   s,HTTP 1.1,HTTP/1.1,

 * 5964+lineAbove:
   LBRACK/RBRACK talk about "square" brackets;
   however, I am seeing curly.

 * 5972:
   Superfluous "(" and ")" around "quoted-string"?

 * 5976:
   s/%x0A/%x0B/ ?

 * Just After 5980: url-parameter:
   "|" before "ttl-param" in .txt (not in PDF).

 * Just Before 5993: media-range:
   Should there be SWS between `"/"' and `"*"'?
   Else, why is it not just "/*" [in [H14.1]]?

 * Just Before 5998: dig-resp:
   I see (here and everywhere) usage like
       foo / bar / [baz]
   Is the meaning of [] in a choice
   documented anywhere?  I turned up nothing. &:(

 * Just Before 5998: digest-uri-value:
   "1.1" is missing after "HTTP/" in .txt. (not
   in PDF).

 * 6002: addr-spec:
   Is "URI" really right, or should it be
   "absoluteURI"?  (As I understand things, "URI"
   would allow for something like "/foo/bar/baz".)

 * 6030: Supported:
   Since "Supported" can be empty, shouldn't this
   be:
       [option-tag *(COMMA option-tag)]

 * 6035: Via:
   Okay.  So I guess I never noticed when IPv6
   properly appeared.  My only concern is that
   this is a non-documented (I think) backward-
   compatability issue, since "[" "]" and ":"
   did not used to be legal in generic parameters,
   but using IPv6 addresses, means that they may
   appear in "received" and/or "maddr".
   Additionally, I think that one could assume
   that the "sent-by" was safe out of harm's
   way from marauding "[" and "]"s.  Not that I
   care, but I think that this should probably
   be mentioned (perhaps in the bullet where
   the introduction of support for IPv6 addresses
   in URIs and Vias is mentioned?).

 * 6043:
   Naughty space nestling in "option- tag"s.

 * 6053:
   Space between "(" and "Section 23.2".

 * 6075:
   "n" missing at end of sentence.

 * 6077:
   "]" missing at end of paragraph.

 * 6133:
   s/THey/They/

 * 6166:
   Add the word "made" before "vastly simpler"?

 * 6167-6169:
   I don't get the last two sentences.  Surely,
   that _is_ "pre-loaded routes"; and I thought
   that we did have full interoperability?

 * 6172:
   Comments can still appear as part of {Retry-After,
   Server, User-Agent}....

 * 6175:
   s/ACK/ACKs/

 * 6219:
   s/so SIP/to SIP/

 * 6234:
   s/mandating/mandated/

 * 6236:
   Change last sentence to "Only 2xx responses to
   INVITEs are retransmitted over TCP.".

Apologies if some of this Just Does Not Make Sense.
In particular, I don't understand BNF or Security.

Or the Offer/Answer Model.

&:)

 - Jo.

_______________________________________________
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: Aymeric MOIZARD <[email-masked]>
Date: Fri, 15 Feb 2002 13:58:19 +0100

The following text is located at line 5925:

             "Removing the contact before adding the response to the
             response contact prevents the next element upstream
             from retrying a location this proxy has already
             attempted."

The "response contact" should be the "response context"?

Aymeric

---

From: Robert Sparks <[email-masked]>
Date: Fri, 15 Feb 2002 13:02:18 -0600

Yes - fixed - thanks.