Subject: [Sip] Comments on draft-ietf-sip-location-conveyance-03

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Mon, 3 Jul 2006 23:51:45 +0100

I have the following comments on the above draft:

Structural
----------

1)	Abstract: From reading the document, it is clear that presence systems are not covered at all in this document for various reasons. Therefore PUBLISH, SUBSCRIBE and NOTIFY are essentially out of scope. It seems to me that this should be made much more explicit in the abstract.

2)	The SIP extension guidelines (RFC 4485) need to be applied to this document, which requires some substantial restructuring. The absence of application of these rules mean that the requirements of the document are extremely unclear. For example RFC 4485 states (section 4.5):

   Developers of protocols often get caught up in syntax issues, without
   spending enough time on semantics.  The semantics of a protocol are
   far more important.  SIP extensions MUST clearly define the semantics
   of the extensions.  Specifically, the extension MUST specify the
   behaviors expected of a UAC, UAS, and proxy in processing the
   extension.  This is often best described by having separate sections
   for each of these three elements.  Each section SHOULD step through
   the processing rules in temporal order of the most common messaging
   scenario.

Absence of this application means that in places in this document it is impossible to determine whether a requirement and its required support occurs as the sender of the location information, or the receiver of the location information.

3)	Section 1 (and possibly section 2) should be redrafted taking into account RFC 4485 section 4.7:

   Too often, extension documents dive into detailed syntax and
   semantics without giving a general overview of operation.  This makes
   understanding of the extension harder.  It is RECOMMENDED that
   extensions have a protocol overview section that discusses the basic
   operation of the extension.  Basic operation usually consists of the
   message flow, in temporal order, for the most common case covered by
   the extension.  The most important processing rules for the elements
   in the call flow SHOULD be mentioned.  Usage of the RFC 2119 [1]
   terminology in the overview section is NOT RECOMMENDED, and the
   specification should explicitly state that the overview is tutorial
   in nature only.  This section SHOULD expand all acronyms, even those
   common in SIP systems, and SHOULD be understandable to readers who
   are not SIP experts. [27] provides additional guidance on writing
   good overview sections.

I found this text much too wordy, and considered that it should be possibly to convey the necessary information to the reader in about half the length.

4)	Section 3 need to have all the RFC 2119 language removed (see history-info and outbound as examples). I remain open as to whether it appears at the start of the document, as here and in history-info, or at the end, as in outbound, but given the length, we may want to consider moving it to the end.

5)	Section 6 should probably follow immediately on from the procedures in the bulk of section 4, and probably be split as in comment 2) above.

6)	Section 7 should be integrated into the main procedures text.

Technical
---------

7)	Section 1, of the three examples given in this introduction, item 2) is out of scope. I had to read an awful lot of text to discover that fact. 

8)	Section 2, 1st paragraph. Probably not appropriate to use the term "trust model". That term is defined in RFC 3324 and RFC 3325, and I am not convinced the usage here is one and the same.

9)	Section 2, 3rd para. 

   No routing of the request based on the location contents is required
   in this case, therefore no SIP Proxies between these two UAs need to
   view the location information contained in the SIP message(s).  The 
   UAC should know certain types of messages will be routed based on 
   the UA's location when creating a message.  

Did not understand what this paragraph is meant to be telling me - can you explain it.

10)	Section 3.1 UAC-4: This is not a generic requirement as it is already identified that certain methods are outside the scope of this document.

11)	Section 3.1 UAC-9, UAC-10: I assume this is specified this way so that misconfiguration releases the location rather than hides it. I believe this contravenes the regulatory requirements of some countries. I believe in Japan privacy requirements are more important that the transmission of the information for emergency calls. If someone from Japan was writing these requirements they would therefore indicate exactly the opposite.

12)	Section 3.2 UAS-6 and section 3.3 Proxy-4. Firstly this is halfway into implementation. Secondly if it is required to address location errors in requests, why is the same consideration not given to location errors in responses. 

13)	Section 3.3 Proxy-1: This merely repeats RFC 3261, rather than developing a new requirement.

14)	Section 3.3 Proxy-3: This seems to be rewriting the requirements to correspond to the solution. I understand the problem is that the solution cannot distinguish between multiple locations, nor understand the reliability, and therefore a receiver may get confused. Firstly this does not seem to me to be a SIP issue, and secondly in general the ability to transport multiple locations could be regarded as useful - they just need some form of assertion as to who provided which location.

15)	Section 4 and elsewhere. I don't find location in responses well described at all. It seems to be an afterthought, rather than something that is decided based on a full set of requirements. I have already made a comment with regard to requirements on error handling. Should we support location in response, or force the UAS to generate a request of its own in order to send a location?

16)	Section 4. Should the instances of "URI" here be "URN".

17)	Section 4 specifies:

   Because a person's location is generally considered to be sensitive 
   in nature, certain security measures need to be taken into account 
   when transmitting such information.  Section 26 of [RFC3261] defines
   the security functionality SIPS for transporting SIP messages with 
   either TLS or IPSec, and S/MIME for encrypting message bodies from 
   SIP intermediaries that would otherwise have access to reading the 
   clear-text bodies.  SIP endpoints SHOULD implement S/MIME to encrypt
   the PIDF-LO message body (part) end-to-end.  The SIPS-URI from 
   [RFC3261] MUST be implemented for message protection (message 
   integrity and confidentiality) and SHOULD be used when S/MIME is not
   used.  

   The entities sending and receiving location MUST obey the privacy 
   and security rules in the PIDF-LO, regarding retransmission and 
   retention, to be compliant with this specification.

   Self-signed certificates SHOULD NOT be used for protecting PIDF-LO, 
   as the sender does not have a secure identity of the recipient.

However RFC 4119 is already normatively referenced which contains the following text:

   For the purposes of this document, only the securing of a PIDF
   document as a whole, rather than element-by-element security, is
   considered.  None of the requirements [10] suggest that only part of
   the information in a location object might need to be protected while
   other parts are unprotected; virtually any such configuration would
   introduce potentials for privacy leakage.  Consequently, the use of
   MIME-level security is appropriate.

   S/MIME [5] allows security properties (including confidentiality,
   integrity, and authentication properties) to be applied to the
   contents of a MIME body.  Therefore, all PIDF implementations that
   support the XML Schema extensions for location information described
   in this document MUST support S/MIME; in particular, they MUST
   support the CMS [6] EnvelopedData and SignedData content types, which
   are used for encryption and digital signatures, respectively.  It is
   believed that this mechanism meets REQs 2.10, 13, 14.1, 14.2, 14.3,
   and 14.4.

   Additionally, all compliant applications MUST implement the AES
   encryption algorithm for S/MIME, as specified in [8] (and per REQ
   15.1).  Of course, implementations MUST also support the baseline
   encryption and digital signature algorithms described in the S/MIME
   specification.

   S/MIME generally entails the use of X.509 [9] certificates.  In order
   to encrypt a request for a particular destination end-to-end (i.e.,
   to a Location Recipient), the Location Generator must possess
   credentials (typically an X.509 certificate) that have been issued to
   the Location Recipient.  Implementations of this specification SHOULD
   support X.509 certificates for S/MIME, and MUST support password-
   based CMS encryption (see [6]).  Any symmetric keying systems SHOULD
   derive high-entropy content encoding keys (CEKs).  When X.509
   certificates are used to sign PIDF Location Objects, the
   subjectAltName of the certificate SHOULD use the "pres" URI scheme.

Which set of text takes precedence?

18)	Section 4:

   More than one location representation or format MAY be included in 
   the same message body part, but all MUST point at the same position 
   on the earth (altitude not withstanding), as this would confuse the 
   recipient by pointing at more than one position within the same 
   message body part.  There MAY be a case in which part or parts of 
   one location format and part or parts of another format exist in the
   same message body part.  These complementary pieces of information 
   MUST point at the same position on the earth, yet are incomplete 
   within their own format. For example, there maybe be a latitude and 
   longitude in coordinate format and a civic altitude value to 
   complete a 3-dimensional position of a thing (i.e. which floor of a 
   building the UA is on in a building at a particular lat/long 
   coordinates pair).

Not sure what "altitude not withstanding" means, particular as this is a RFC 2119 MUST sentence.

Additionally, the paragraph repeats the essence of the "same position on the earth" in two separate MUST statements.

19)	Section 4:

   There MAY be more than one PIDF-LO in the same SIP message, but each
   in separate message body parts. Each location body part MAY point at
   different positions on the earth (altitude not withstanding).  If 
   the message length exceeds the maximum message length of a single 
   packet (1300 bytes), TCP MUST to be used for proper message 
   fragmentation and reassembly.  

Why is the final sentence stronger than RFC 3261. I assume your thinking is emergency calls, but that is only one of the uses of this document. And surely if emergency calls is the problem, then the requirement has to be made as an update to RFC 3261 for all emergency calls, not just those that happen to carry location.

20)	Section 4:

   Several push-based SIP Request Methods are capable (and applicable) 
   of carrying location, including:

      INVITE, 
      REGISTER, 
      UPDATE, and
      MESSAGE, 

   While the authors do not yet see a reason to have location conveyed 
   in the ACK, PRACK, BYE, REFER and CANCEL Methods, we do not see a 
   reason to prevent carrying a PIDF-LO within these Method Requests as
   long as the SIP message meets the requirements stated within this 
   document.  Discussing Location in the PUBLISH Request Method will be
   for another document.  

The draft seems to go to a great deal of effort to ensure the information is carried end to end, but then suggests that the information might be entrusted to non end-to-end messages. I would suggest that the header and body are declared out of scope for ACK and CANCEL.

21)	Section 4:

   A 200 OK to a SIP Request MAY carry the UAS's PIDF-LO back to the 
   UAC that provided its location in the original request, but this is 
   not something that can be required due to the timing of the request 
   to 200 OK messages, with potential local/user policy requiring the 
   called user to get involved in determining if the caller is someone 
   they wish to give their location to (and at what precision).

I don't understand what this is trying to convey. Please explain?

22)	Section 4.1:

   It is envisioned that HTTP, through the http_URL in [RFC216], and 
   HTTPS [RFC2818] MAY be used to dereference a location-by-reference 
   PIDF-LO.

Do we place any requirement to support HTTP at any location receiver, so that location by reference when received actually works?

23)	Is it not sufficient to say that RFC 2119 applies, and therefore the security considerations of RFC 2119 applies.

NITS
----

24)	Section 3.1 UAC-8: As by-reference doesn't carry the PIDF-LO within SIP, but within HTTP, the text is wrong.

25)	Can we consistently use "request" or "response" rather than "message" following RFC 3261 terminology?

26)	Section 4:

   Several push-based SIP Request Methods are capable (and applicable) 
   of carrying location, including:

      INVITE, 
      REGISTER, 
      UPDATE, and
      MESSAGE, 

   While the authors do not yet see a reason to have location conveyed 
   in the ACK, PRACK, BYE, REFER and CANCEL Methods, we do not see a 
   reason to prevent carrying a PIDF-LO within these Method Requests as
   long as the SIP message meets the requirements stated within this 
   document.  Discussing Location in the PUBLISH Request Method will be
   for another document.  

This document is under WG control, the contents have nothing to do with the authors vision!!

27)	Section 4.1: 1st para: delete "and IANA registers" as superfluous and change "is to be used" to "can be used"

28)	Suggest using lower case throughout, including initial letter, for the name of the option-tag. 

29)	Section 4.1, table of headers needs a table number. As it follows the conventions of RFC 3261 (as indicated by reference), it should have an empty space under the "where" column. However see other technical comments about appearance in responses.

30)	Section 4.2, delete the words "a new 4XX level error is created here", as this is totally obvious from the rest of the words.

31)	Section 9. Delete "4xx error" before "response code"

regards

Keith

Keith Drage
[email-masked]
tel: +44 1793 776249

_______________________________________________
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: "James M. Polk" <[email-masked]>
Date: Mon, 03 Jul 2006 22:17:42 -0500

At 11:51 PM 7/3/2006 +0100, Drage, Keith (Keith) wrote:
Keith

in-line

>1)      Abstract: From reading the document, it is clear that presence 
>systems are not covered at all in this document for various reasons. 
>Therefore PUBLISH, SUBSCRIBE and NOTIFY are essentially out of scope. It 
>seems to me that this should be made much more explicit in the abstract.

The first line of the abstact states:

"This document defines how the Session Initiation Protocol (SIP) conveys, 
or pushes, geographic location information from one SIP entity to another 
SIP entity."

Since SUB/NOT is not a "push" form of transaction, I believe this satisfies 
what you are looking for.  I admit I do not call out each of the 14 Methods 
that this extension does affect, but I rarely see this done in any SIP 
document, so I didn't know it was necessary here. For example RFC 4538 
doesn't say in the abstract it is only used in INVITE, SUB and NOT, and not 
all the others.

Section 4 clearly states that this extension can be used in SUB and NOT, 
but this is out of scope for this document because they are pull based 
transactions.  Section 4 also states that PUB is out of scope.

>2)      The SIP extension guidelines (RFC 4485) need to be applied to this 
>document, which requires some substantial restructuring.

I believe this will only result in section 4 and 5 being modified, and not 
any other section (structurally - unless the reqs are moved to an appendix)

>The absence of application of these rules mean that the requirements of 
>the document are extremely unclear. For example RFC 4485 states (section 4.5):
>
>Absence of this application means that in places in this document it is 
>impossible to determine whether a requirement and its required support 
>occurs as the sender of the location information, or the receiver of the 
>location information.

This document is written almost exclusively as a UAC pov extension, since 
it, by definition, is what is "conveying" location.  Thus, little about 
this document is about a UAS, save a line that discusses that element can 
response with location.

A little bit more of this doc discusses what a proxy does with this 
extension, with most of the original material from past version removed, to 
be put into ECRIT documents.

I will make element operation wrt this extension much more explicit in the 
next rev.

>    the extension.

This document, per a conversation between you, me and Dean, in Dallas, is 
to include the requirements for this extension in the front of the 
document, and not deleted or put in an appendix.  This is due to this 
document origin as a SIPPING Requirements document.  This means I have to 
get to the requirements section, which is section 3.  This means I cannot 
get into the classic "Basic Operation" until the section after that - 
Section 4.  Section 4 states it is a Basic Operation section at the top of 
the third paragraph, followed by the two basic message flows (Figure 1 and 
2).  Perhaps I should have called the section "Basic Operation of SIP 
Location Conveyance" instead of "Location Conveyance Using SIP". I will fix 
this in the next rev.  But section 4 is what you are looking for per RFC 
4485 section 4.7.

>The most important processing rules for the elements
>    in the call flow SHOULD be mentioned.

they are

>Usage of the RFC 2119 [1]
>    in nature only.

I do need to work on this.  This will be addressed in the next rev.  There 
is a good segway in section 4 right now, I just didn't divide that point 
into a new section - but I will now.

>This section SHOULD expand all acronyms, even those
>    are not SIP experts.

I believe it does

>[27] provides additional guidance on writing
>    good overview sections.
>
>I found this text much too wordy, and considered that it should be 
>possibly to convey the necessary information to the reader in about half 
>the length.

"this text" meaning exactly what text? Section 1, Section 2 or both?  I 
think section 1 is discussing scenarios that offer unique ideas about 
location conveyance, and what is going into which section.  Section 2 has 
more words than it probably should.

>4)      Section 3 need to have all the RFC 2119 language removed (see 
>history-info and outbound as examples).

Section 3 is only requirements, and you said in Dallas they stay where they 
are because this ID stated as a Reqs only doc in SIPPING, so I'm confused 
as to which you want.

>I remain open as to whether it appears at the start of the document, as 
>here and in history-info, or at the end, as in outbound, but given the 
>length, we may want to consider moving it to the end.

Again, this is where you said to keep them (in Dallas), so I did.  Are you 
changing your mind?  If so, given that you hadn't told me prior to after 
the document deadline, I'm not surprised I didn't do it another way.  That 
said, I can move the reqs to an appendix, and mention this is where they 
are in section 1.

>5)      Section 6 should probably follow immediately on from the 
>procedures in the bulk of section 4, and probably be split as in comment 
>2) above.

Based on what you said above, I agree that section 4 and 5 will be modified.

>6)      Section 7 should be integrated into the main procedures text.

hmm... I think calling out how this SIP extension complies with RFC 3693 in 
its own section is appropriate (readers can see this glaring at them in the 
TOC), but it doesn't make sense until the extension is explained, which 
would be hard to undertand before section 5.

>Technical
>---------
>
>7)      Section 1, of the three examples given in this introduction, item 
>2) is out of scope. I had to read an awful lot of text to discover that fact.

I disagree. Think of the REGISTER request, in which a Registrar responds 
with different information based on where the UAC is.

I have a couple of IDs in another WG that take this usage and run with it:
http://www.ietf.org/internet-drafts/draft-polk-ecrit-lost-server-uri-00.txt
http://www.ietf.org/internet-drafts/draft-polk-ecrit-emergency-dialstring-00.txt
http://www.ietf.org/internet-drafts/draft-polk-ecrit-mapping-during-registration-00.txt

>8)      Section 2, 1st paragraph. Probably not appropriate to use the term 
>"trust model". That term is defined in RFC 3324 and RFC 3325, and I am not 
>convinced the usage here is one and the same.

Should I use "e2e trust" vs. non-e2e trust"?

3325 talks about the UAS trusting the Proxy to assert the PAI is accurate 
about the UAC.

Here, this is from the UAC's pov, and making a decision based on where it 
believes the information will be used (only at the destination UAS, or by a 
proxy to use for message routing based on where the UAC is).  This seems 
like a model; either e2e or used by an intermediary to get the message to 
the right endpoint.

Any suggestions?

>Did not understand what this paragraph is meant to be telling me - can you 

yes

In the previous paragraphs it was concluded by the UAC no help was needed 
in the network, from a location conveyance pov, to find the destination 
UAS, therefore merely sending location in the message body was enough.  The 
forth paragraph continues this train of thought stating RFC 3261 does not 
allow message bodies to be modified or deleted, and if a UAC wants location 
to be conveyed confidentially, it needs to employ an encryption mechanism 
(S/MIME).  Paragraphs 2, 3 and 4 could be a single, larger paragraph - but 
I broke it up.  Perhaps that was a mistake.

>10)     Section 3.1 UAC-4: This is not a generic requirement as it is 
>already identified that certain methods are outside the scope of this document.

This allows Location to be included in other SIP Requests (than those 
listed above this requirement).  Without this requirement, table 2 and 3 
would be pretty empty (with only INVITE dialog related requests with an 
'o', and everything else having a '-', meaning not allowed, and the doc 
states that 'some other Request MAY include location, but the authors do 
not see a reason for this at this time'.

>11)     Section 3.1 UAC-9, UAC-10: I assume this is specified this way so 
>that misconfiguration releases the location rather than hides it.

that's what UAC-9 is for, also if the first INVITE hid location, but a 
subsequent message (after recieving a 424) doesn't want to hide it to make 
sure this isn't the reason the message didn't get through.

UAC-10 allows for a user to "not" include location during an emergency 
call.  We already know of places that have this law on the books.

>I believe this contravenes the regulatory requirements of some countries.

Yes, and in those jurisdictions, that's an configuration issue, not a 
protocol issue.  My mobile phone needs to be able to roam between a 
jurisdiction that has such a law, and one that doesn't.

>I believe in Japan privacy requirements are more important that the 
>transmission of the information for emergency calls. If someone from Japan 
>was writing these requirements they would therefore indicate exactly the 
>opposite.

Again, this is an configuration issue.  There are places where the user has 
no choice in the matter, other places the user has a choice.

>12)     Section 3.2 UAS-6 and section 3.3 Proxy-4. Firstly this is halfway 
>into implementation. Secondly if it is required to address location errors 
>in requests, why is the same consideration not given to location errors in 
>responses.

Are you asking if there is an error in a SIP response?  How do you address 
that anytime?

Basically, I'm not understanding your question/comment 12. Can you rephrase?

>developing a new requirement.

Fair - it does. I guess this was to remind readers of this.  It should be 
removed.

>14)     Section 3.3 Proxy-3: This seems to be rewriting the requirements 
>to correspond to the solution.

I disagree.  We have a problem in that there is no indicator of who 
generated a PIDF-LO (by-value or by-reference).  This is very real.  This 
requirement is stating that if there already is location in a message, not 
to add to the confusion factor if you can help it.

>I understand the problem is that the solution cannot distinguish between 
>multiple locations, nor understand the reliability, and therefore a 
>receiver may get confused. Firstly this does not seem to me to be a SIP 
>issue, and secondly in general the ability to transport multiple locations 
>could be regarded as useful - they just need some form of assertion as to 
>who provided which location.

but there is no form of assertion now... so what do we do, ignore the 
problem as it is today?

>15)     Section 4 and elsewhere. I don't find location in responses well 
>described at all.

I state that " Bob MAY choose to include his location in a response back to 
Alice."  Otherwise, I don't get into this other than it must obey the 
PIDF-LO format and privacy mechanisms of a request.

>It seems to be an afterthought, rather than something that is decided 
>based on a full set of requirements. I have already made a comment with 
>regard to requirements on error handling. Should we support location in 
>response, or force the UAS to generate a request of its own in order to 
>send a location?

fair question - I'm guess I'm ok with saying Location Conveyance is only in 
requests, but I didn't see the harm in Location being in a 200 OK to a 
request that had location in it.  Guidance/opinions welcome

>16)     Section 4. Should the instances of "URI" here be "URN".

I take URNs to be services (like urn:services:sos), and URIs to be records 
on a remote node to be accessed.  Based on that, I think locations are 
URIs, of which, a URL is a subset.

>Which set of text takes precedence?

I don't see the conflict.  Can you point any such conflict out?

Is it the SHOULD vs. MUST implement S/MIME?  If so, I'll change this ID 
back to MUST implement.

>Not sure what "altitude not withstanding" means, particular as this is a 

It means with or without, it makes no difference.  There are 4000 datums. 
Some in 2D, and others in 3D.  WGS84 has both.  There is a movement in 
Geopriv to have coordinate format location only provide 2D and a civic 
format provide altitude within the same <location-info> element of the 
PIDF-LO.  This statement is regarding during times where civic is not 
supported, or a altitude is not available, consider the 2D location to be 
enough information to present location by.

>Additionally, the paragraph repeats the essence of the "same position on 
>the earth" in two separate MUST statements.

I'll work on that, I was attempting to cover a separate angle of the same 
meaning.

>Why is the final sentence stronger than RFC 3261. I assume your thinking 
>is emergency calls, but that is only one of the uses of this document. And 
>surely if emergency calls is the problem, then the requirement has to be 
>made as an update to RFC 3261 for all emergency calls, not just those that 
>happen to carry location.

hmmm... so this is a problem.  I hadn't made that distinction wrt 3261 
language.  If I change this to a SHOULD, will that be acceptable?

>The draft seems to go to a great deal of effort to ensure the information 
>is carried end to end, but then suggests that the information might be 
>entrusted to non end-to-end messages.

Maybe I'm missing where a message other than 100 Trying is not 
end2end.  Certainly all requests are intended to be e2e.

>I would suggest that the header and body are declared out of scope for ACK 
>and CANCEL.

I can modify the above to state 'we do not see the point/reason of 
including location in either ACK or CANCEL'.

>I don't understand what this is trying to convey. Please explain?

A 200 OK can carry Location back to the UAC; however, this cannot be an 
expected operation due to the user of the UAS possibly needing to get 
included in whether or not to include their location to the user of the 
UAC.  This delay may be based on who the UAC user is.  This could greatly 
delay call set-up, and delay sending of any response message to the UAC.

Or, the UAS user may have a policy to let certain offerers know the UAS's 
location if they match certain rules within the request (i.e. are on a 
buddy list).

I'm finding this answer to be awkward, but I feel something needs to be 
said here that a UAS may or may not response with location, based on some 
rule match in the request.

suggestions are welcome.

>Do we place any requirement to support HTTP at any location receiver, so 
>that location by reference when received actually works?

JDR got on me about lacking a means to dereference a 
location-by-reference.  Since I don't believe we need another lame usage 
for SIP INFO, I thought we'd suggest that HTTP would be a good fetching 
protocol for a PIDF-LO not locally stored.

What should I do here, change the BNF

         locationURI = absoluteURI / cidURI
to
         locationURI = http_url / https_url / absoluteURI / cidURI
  or
add a requirement in section 3 that receivers of a location by reference 
URI be able to use HTTP/HTTPS to dereference the PIDF-LO?

>23)     Is it not sufficient to say that RFC 2119 applies, and therefore 
>the security considerations of RFC 2119 applies.

I do not understand this comment.  Can you be more verbose?

>NITS
>----
>
>24)     Section 3.1 UAC-8: As by-reference doesn't carry the PIDF-LO 
>within SIP, but within HTTP, the text is wrong.

I think within a by-value message body, it is within SIP.  If I understand 
your point above (about 2 inches), you think this requirement needs to 
change where it states location by-reference within HTTP/HTTPS, correct?

>25)     Can we consistently use "request" or "response" rather than 
>"message" following RFC 3261 terminology?

fair point.  I will change all transactions to requests and responses.

>This document is under WG control, the contents have nothing to do with 

OK, and this usage of pov is quite prevelent in documents.  Nonetheless, I 
will change it to omit author's visions.

>27)     Section 4.1: 1st para: delete "and IANA registers"

this comes from an old correction made by an AD (who said to always say 
this if a doc registers anything), but I will remove it

>as superfluous and change "is to be used" to "can be used"

ack

>the name of the option-tag.

For the option-tag, I thought I had - but I will make sure of 
this.  Location wrt the header needs to be upper case though (correct still?).

>29)     Section 4.1, table of headers needs a table number.

ack

>As it follows the conventions of RFC 3261 (as indicated by reference), it 
>should have an empty space under the "where" column.

my mistake

>However see other technical comments about appearance in responses.
>
>30)     Section 4.2, delete the words "a new 4XX level error is created 
>here", as this is totally obvious from the rest of the words.

ack

>31)     Section 9. Delete "4xx error" before "response code"

ack