Subject: [Geopriv] draft-winterbottom-geopriv-pdif-lo-profile-00 review

From: "James M. Polk" <[email-masked]>
Date: Wed, 09 Mar 2005 00:08:36 -0600

James

I have a few comments about you ID

I don't agree with your rule #1 as you have set it up. A PIDF-LO can 
contain a subset of a complete location. In fact, I would argue that only 
the one field that is necessary to route the message correctly could be the 
only Location-info field in the LO.

I think rule #2 are is in place, unless you are referring to a postal 
address being in a separate tuple than a legal address. In such a case, I 
think it is a waste of bytes to have full tuples when only one field may be 
different - and can both can be adequately marked as such.

Rule #3 violates laws in some counties; Sweden for one. In that country, 
the 'current' location must be given, as well as the billing address of the 
end-user in the same message. It is the law there. So rule #3 cannot be a MUST.

Rule #3 says MUST to the same thing Rule #4 says SHOULD. This needs to be 
resolved going forward.

Rule #5 violates the same law pointed out regarding Rule #3, so this cannot 
be a MUST.

I'm not sure I see how Rule #5 differs from #6. One ought to go.

Rule #7 is not necessary as a parser should be able to figure this out very 
quickly, and that needs to be a MUST in itself.

I'm not sure I understand what prioritizing the tuples will accomplish in 
Rule #8. Can you explain this more?

Same goes for Rule #9, why is this important? And why would a UA know to do 
something 'right'?

Section 3.1 - how does Jane's laptop know it is a complete LO? In other 
words, what defines maximum resolution, even in the civic case?

Section 3.2 - why did you combine geo and civic here when 3825 defines how 
to indicate floors and subfloors above and below ground level? You're 
looking here to save bits and you added many you didn't need - other than 
defining a country value 3825 doesn't allow, which makes this construct not 
possible with you reference to [6]. In your conclusion sentence, you don't 
mention that the country field was even needed, BTW.

Section 3.3 has a Proxy "...inserting a new PIDF-LO indicating her new 
location." This is in violation of SIP rules in 3261, thus this section 
needs to be revised.

Further, returning her location in an error message is written into the SIP 
Location Conveyance ID, but that piece has not met the approval by the 
SIP/SIPPING chairs yet, so I wouldn't count on this - but could use you 
help in swaying them this is a good idea.

Section 4 makes a good point about something we in the IETF didn't expect: 
GML to change things like this.

I'll continue this review after some sleep, but I think this is a good 
start for discussion.

cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented

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