I have a couple comments on the suggested changes, inline: > > Section 3 says: > > ... A server MUST NOT include Returned Location > Information using a location profile that differs from the profile of > the location used to answer the query and, by extension, MUST NOT > include Returned Location Information using a location profile that > was not used by the client in the request. > > Can this be turned into a simple MUST statement? Perhaps: > > ... A server MUST include only Returned Location > Information using a location profile that was used by the > client in the request. I would prefer to avoid this simplification. Although I think the meaning is intended to be the same, it is actually not. The query can contain multiple locations in different profiles (but that derive from the same baseline profile), so the first restriction given is more restrictive than the second, which only follows as a consequence of the first. The suggested text eliminates the more important restriction. This could be fixed simply enough, however I also wish to avoid any chance that someone could interpret it wrongly. I've spent too much time arguing with people over the precise meaning of language in other specifications, and I believe the current language provides less opportunity for that. My preference is to keep the original text. But if we were to change it to a single MUST statement, I would word it as follows: When a server includes Returned Location Information, that Information MUST use the same location profile as the location used to answer the query. > > Section 3 says: > > In a LoST <findServiceResponse> indicating a Valid Location i.e., > containing the <locationValidation> element with no elements listed > as invalid, the LoST server can use this extension to include > additional location information in a <locationValidation> element. > > I think this would be more clear if it defined a Valid Location, and then use > this definition: > > A Valid Location contains a <locationValidation> element without any > elements listed as invalid. In a LoST <findServiceResponse> > indicating a Valid Location, the LoST server can use this extension > to include additional location information in a <locationValidation> > element. > I'm not opposed to the idea of defining Valid Location, but we already do that in section 2. This description is also in error - the location itself does not contain a <locationValidation> element; the response does. If anything, we could refer the reader back to section 2, or even omit the explanation entirely: In a LoST <findServiceResponse> indicating a Valid Location, the LoST server can use this extension to include additional location information in a <locationValidation> element. But I do think the reminder of what indicates a Valid Location is useful here, so I slightly prefer the original text. Dan Banks -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
