Subject: Re: [Geopriv] Nits on draft-ietf-geopriv-http-location-delivery-10.txt

From: "Mary Barnes" <[email-masked]>
Date: Tue, 25 Nov 2008 12:41:42 -0600

-----Original Message-----
From: Barnes, Mary (RICH2:AR00) 
Sent: Tuesday, November 25, 2008 12:39 PM
To: 'DRAGE, Keith (Keith)';
[email-masked]
Subject: RE: Nits on draft-ietf-geopriv-http-location-delivery-10.txt

Hi Keith, 

Responses are embedded [MB]. Note, I've also copied this list, since
this doc is post IETF-LC, I'm not comfortable even making proposed
"editorial" changes, particularly with regards to the 2119 language
without the WG being aware. 

Mary.

-----Original Message-----
From: DRAGE, Keith (Keith) [mailto:[email-masked]]
Sent: Tuesday, November 18, 2008 10:37 AM
To: [email-masked]
Subject: Nits on draft-ietf-geopriv-http-location-delivery-10.txt

For example in this text but general:

4.2.  Location by Value

   Where a Device requires LI directly, it can request that the LIS
   create a PIDF-LO document.  This approach fits well with a
   configuration whereby the device directly makes use of the provided
   PIDF-LO document.  The details on the information that may be
   included in the PIDF-LO MUST follow the subset of those rules
   relating to the construction of the "location-info" element in the
   PIDF-LO Usage Clarification, Considerations and Recommendations
   document [I-D.ietf-geopriv-pdif-lo-profile].  Further detail is
   included in the detailed protocol section of this document Section 6

5.2.  Location Request

   A location request message is sent from the Device to the LIS when
   the Device requires its own LI.  The type of LI that a Device
   requests is determined by the type of LI that is included in the
   "locationType" element.

   The location request is made by sending a document formed of a
   "locationRequest" element.  The LIS uses the source IP address of the
   location request message as the primary source of identity for the
   requesting device or target.  It is anticipated that other Device
   identities may be provided through schema extensions.

   The LIS MUST ignore any part of a location request message that it
   does not understand, except the document element.

5.3.  Location Response

   A successful response to a location request MUST contain a PIDF-LO
   and/or location URI(s).  The response SHOULD contain location
   information of the requested "locationType".  The cases whereby a
   different type of location information MAY be returned are described
   in Section 6.2.

5.4.  Indicating Errors

   If the LIS is unable to provide location information based on the
   received locationRequest message, it MUST return an error message.
   The LIS may return an error message in response to requests for any
   "locationType".

Part of the rules I am formulating for best practice in SIP (and I know
this is not SIP) say:

5.	Avoid statements like "The xxxx request MUST contain an yyyy
header." Such statements potentially mask two RFC 2119 statements, i.e.:
The UAC MUST include a yyyy header in any xxxx request the UAC sends"
and "The UAS MUST ensure that a yyyy header is received in any xxxx
request before processing the request". One or both of these may be
intended by the draft editor, and thus the original statement is
ambiguous.

2.	Include the name of the actor directly in the active clause,
i.e. "If the UAC does xxxx THEN the UAC MUST perform yyyy".

[MB] Yes, this is not SIP, so we've not written our docs separating out
LIS requirements for implementing the protocol from Device requirements.
So, I'd like to hear other feedback. The doc has passed Gen-ART review
and I don't necessarily think that SIP practices apply to all docs,
since the protocol requirements apply equally to the LIS and Device and
the HELD protocol is exponentially simpler than SIP. Thus, I do not
believe there is a risk of getting the implementation wrong. There are
already two implementations that have had no problem interpreting the
spec. [/MB]

I also have a preference for avoiding lower case forms of RFC 2119
language which is endemic throughout this text. It is oh so easy for
this to get converted to upper case at the touch of a word processing
button, and many external readers do not understand the distinction as
it is in the drafting rules of so so few other groups. Can we make an
attempt to get rid of some of it.
[MB] If you can point out these instances, I'd appreciate it - we have
made several editorial sweeps to remove (changing "mays" to "can" or
"could", etc.) and it is more likely that a LC must that should really
be UC was inadvertently added. I already have a list of some that need
changing, so I'd rather do this carefully. I will double check the next
round of updates. While I agree in the end this can cause problems, I
also think this could be something handled by RFC editor - they seem to
do a decent job with this for the most part and the doc can be carefully
reviewed then. I've yet to have a doc that didn't need changes during
AUTH48 and based upon the docs that have gone thru SIPPING WG, this
seems to be very, very common. [/MB]

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