Subject: [Sip] Re: Comments on Location Conveyance -06

From: "James M. Polk" <[email-masked]>
Date: Sat, 10 Feb 2007 19:35:38 -0600

Matt

I apologize for getting back to this so late. I believe I have corrected 
all the points you brought up below.  Thanks for your review!

see comments in-line

At 02:50 PM 1/4/2007 -0500, Matt Lepinski wrote:
>James,
>
>Here are some comments on the latest conveyance draft. I generally like 
>the document, so it's mostly small stuff, but hopefully helpful, nonetheless.
>
>First, you refer
>
>Section 1: Introduction
>----------------------------
>I have trouble understanding the last sentance of the first paragraph. 
>Consider condensing the sentence. For example,
>"We use the term "conveyance" to distinguish this work from other 
>cirmustances in which location is used, such as location sighting or 
>location configuration."
>The above sentance might be too vague, another possibility:
>"We use the term "conveyance" to distinguish this work from other 
>circumstance in which location is used, such as the initial generation of 
>location information or the acquisition of location information by the SIP 
>entity."

Done, by rewriting the sentence to

" This document uses the term "conveyance" to describe scenarios in which a 
SIP user agent client (UAC) is telling or informing a user agent server 
(UAS) where the UAC is.  This is different from a UAC asking or seeking the 
location of where the UAS is.  Conveyance is a push model, where seeking is 
a pull model, and therefore not discussed here."

>Section 3.3: 424 Response Code
>---------------------------------------
>The final sentance of the final paragraph reads:
>"An initial set of location error codes are in [ID-ERROR]"
>I don't know if a concesus was reached regarding the future of the 
>ID-ERROR (Geopriv error code registry draft).
>However, it seems that either:
>- The reference to ID-ERROR should be removed because the ID-ERROR draft 
>is not moving forward,
>or else
>- Additional text should be added to clarify the relationship between the 
>error code registry draft and the new warning codes provided in Section 3.4

Done, by removing the ID-ERROR ref and pointing to sec 3.4 where the new 
Warning codes were added.

>Section 3.4: New Warning Codes for Location Error Granularity
>-----------------------------------------------------------------------------
>The final sentance of paragraph 2 should read:
>"This can be useful for troubleshooting."  (added the word 'be')

done

>Section 3.4.1
>----------------
>The third sentance reads: "... only understood location in RFC4119 PIDF-LO 
>format (civic or geo)."
>In this context it may be unclear to the reader what you mean by "geo".

Done, by changing every reference to "coordinate" format.

>I'm not sure what you should call the format that's not civic, but it's 
>important to be consistant (and as clear as possible).
>In this document, you refer to "geo" in 3.4.1, "Geo-location Format" in 
>3.4.2, and "Coordinate Format" in 4.1
>Also, RFC 4119 refers to this format as GML 3.0, and the LoST drafts refer 
>to this format as "Geodetic Coordinate".
>So basically, I don't know how you should refer to this format, but using 
>"geo" as short hand without defining it, may cause confusion.

Regarding LoST and 4119, this doc cannot control either of their wordings

>(Also, consider adding a space between RFC and 4119.)

Fixed for all RFCs mentioned

>Next, in the 5th (second to last) sentence of the first paragraph, the 
>'SHOULD' is capitalized, but in the last sentence the 'should' is not 
>capitalized. My inclination is that since these are just examples, the 
>'should' should not be capitalized in either case. However, if you want 
>the text to be normative, you should captialize both occurances of 'should'

I agree, and changed the SHOULD to a should.

>Section 3.4.3
>----------------
>In the second paragraph, the word 'Warning' probably does not need to be 
>capitolized.

fixed

>Section 3.4.4
>----------------
>The first sentance is missing a comma and should read:
>"... means the location provided, whether by-value or by-reference, in a 
>request is not well formed."

fixed

>Section 3.4.5
>----------------
>I found the second paragraph to be unclear. Consider re-wording it as follows:
>"A typical reaction to receiving this warning code is for the location 
>sender to verify that it has indeed included location information in the 
>request and then to send the request again."

reworded as requested here

>Section 3.4.6
>----------------
>In the second paragraph, consider changing 'error' to 'warning code' for 
>consistancy.

done

>Section 3.4.7
>----------------
>Consider re-wording the second paragraph as follows:
>"A typical reaction to receiving this warning code is for the location 
>sender to convey more information, if doing so is allowed by local policy."

done - and added the word 'location' in front of "information" for 
clarification of what type of info is to be sent.

>Section 3.4.12
>-----------------
>In the second paragraph, consider changing 'error' to 'warning code' for 
>consistancy.

done

>Section 3.6
>--------------
>In the last sentance of the first paragraph, consider adding a space 
>between RFC and 3693.

done for all RFCs

>I had trouble understanding the first sentance of the second paragraph. 
>Consider a re-wording such as:
>"... treating the URI as a presence URI and dereferencing it by sending a 
>SUBSCRIBE request to a presence server as per [RFC3856]."

Done as suggested

>In the last sentance of the third paragraph, add the word 'is' before the 
>phrase 'the purpose of this extension'

done

>Section 5
>-----------
>In the fourth paragraph, add the word 'a' between 'for protecting' and 'PIDF'
>
>Consider rewording the first sentance of the last paragraph as follows:
>"... in the same SIP message, so long as each is in a separate message 
>body part."

both done

>Section 5.1
>-------------
>In the first sentance of the third paragraph, consider adding the phrase 
>'or wish to convey' between 'does not know' and 'its location at this time'.

done

>In sentance three of paragraph five, I find the phrase 'learn from the 
>Warning code' to be unclear. Consider re-wording the sentance as follows:
>"Upon receiving an error response, the UAC SHOULD take appropriate steps 
>based on the warning code before attempting to convey location again."

done

>I had trouble with the final paragraph of this section. I understand that 
>if the UAC has a problem with location information sent by the UAS it 
>doesn't have an oppertunity to send a warning code and should just ignore 
>the information. However, you go on to say that "A subscription is a 
>better means of getting a UAS's location". By 'a subscription' do you mean 
>location-by-reference as opposed to location-by-value? Also, it's not 
>clear why a subscription is a better way of obtaining the location of a 
>UAS. Perhaps you could write a small amount of additional text clarifying 
>this notion.

fixed by adding "A UAC subscribing to a UAS for its location is a better 
means of acquiring the UAS's location.  This is a seeking or pull model 
scenario, which is not defined here, and left for future study."

>Section 5.2
>--------------
>Consider re-wording the first sentance of the first paragraph as follows:
>"... is present, the type of URI contained in the header field will 
>indicate if location ..."

done

>In the first sentance of the second paragraph, consider changing "or error 
>the message" to "or else send an error response"

done

>Section 5.3
>-------------
>Consider re-wording the first sentance of the first paragraph as follows:
>"Proxies that perform location-based routing may need to consult external 
>databases or systems to determine the route."

I think you mean the 1st sentence of the fourth paragraph, not the first. I 
fixed that sentence in paragraph 4.

>Section 5.3.1
>----------------
>In the first sentance of the first paragraph, consider adding the word 
>'geolocation' between 'any existing' and 'header'.

done

>The first paragraph indicates that any existing header parameter MUST NOT 
>be modified or deleted by a proxy. However, the last paragraph describes a 
>case where the proxy MUST remove the incoming 
>"message-routed-on-this-uri". If "message-routed-on-this-uri" is a header 
>parameter than this is a contradiction. (Alternatively, if this is not a 
>contradiction, then it's unclear to me what a header parameter is).

Agreed, so I changed the paragraph to:

" When a message traverses a SIP intermediary, any existing Geolocation 
header value (URI or header parameter) MUST NOT be  deleted.  A Geolocation 
header value (URI or header parameter) MAY only be modified to indicate if 
the message was routed based on a specific geolocation URI.  Further 
modification of this Geolocation header MUST NOT occur.  For example:..."

Thanks!

James

_______________________________________________
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