Subject: Re: [Uri-review] Review request of draft-ietf-geopriv-geo-uri

From: "Alexander Mayrhofer" <[email-masked]>
Date: Mon, 3 Aug 2009 14:06:03 +0200

Hello Björn,

I'm currently working on an update of the draft, and have a couple of open questions regarding the points you raised. 

A preliminary version of the new draft is attached, i plan on posting that version tomorrow or later today.

> It references RFC 4234 which has been obsoleted by RFC 5234.

Thanks, done.
 
> Section 9.1 is contradictory, it calls geo:94,0 both valid 
> and invalid.

Changed so that it now reflects the fact that the URI might be technically valid, but refer to an invalid locations.
 
> I believe section 7 should be marked non-normative.

Done.

> In section 6.2. the markup is improperly wrapped. It should be wrapped
> e.g. after the "<a " as white space may occur there, but not where it
> is currently specified.

Done.
 
> In 6.2. "URI parameter" should be just "parameter" or use some other
> term; there aren o "URI parameters".

Done.

> Section 4.11 is redundant and should be removed. The filled 
> out template
> need not be a standalone document. (Also section 4.8.)

Done.
 
> I find the formatting in 4.9. unfortunate, and would prefer something
> like the following
> 
>    Christian Spanring <[email-masked]>
>    Alexander Mayrhofer <[email-masked]>

Done. 
 
> In 4.7. I find this questionable
> 
>    Poorly authored 'geo' URI instances could contain whitespace and
>    values with leading plus signs ("+"), which is not allowed 
> according
>    to the ABNF.  Clients SHOULD, however, try to dereference such URIs
>    after removing such whitespace and plus signs.
> 
> Why disallow it and then require clients to accept them anyway? If the
> characters in question continue to be disallowed, it should be
> emphasized that they are invalid and malformed, not poorly authored.

I have now changed that to "MAY" - an alternative would be to remove that entirely - which option would you prefer? 

I though of having this text in the sense of "be conservative what you send, and liberal what you accept"..

> I could not immediately locate how clients are to handle multiple crs
> parameters. A similar problem may exist for using too many digits in,
> say, latitude.

Section 4.3 already specifies that "crs" (and the new "u") parameter MUST NOT occur more than once each. I haven't added any text regarding the "too many digits" problem, and have been looking for similar text for other URI schemes - but haven't found any... I think that any options here would be contagious (eg. Allowing the client to drop URIs with "too many" digits, and recommending authors to not create such URIs?). Any advice appreciated..
 
> It appears the scheme registration does not state considerations for
> internationalization, such as handling of non-ascii characters. This
> needs to be added, if only by saying that only ascii is allowed even
> in %xx sequences and that implementations must reject any such URIs
> with no attempt at recovery.

Section 4.5. contains text about encodings. Does it make sense to add the text there, or would you prefer an additional "Internationalization Considerations" section within section 4?

> (As an aside, it strikes me as bad practise to start a memo with a log
> of changes).

Noted - it seems to be a matter of taste - for some other RFCs i did, people explicitely asked for those "change log" sections to be close to the front of the document.

Thanks again for the comprehensive review.

Alex

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 06 Aug 2009 08:45:23 +0200

* Alexander Mayrhofer wrote:
>I have now changed that to "MAY" - an alternative would be to remove that
>entirely - which option would you prefer?

URIs cannot contain white space, unless you mean as, say, %20, or in
higher level protocol elements like attributes in markup languages. In
case of the latter, the markup language likely has its own rules for
handling them. So remove it for white space. For "+" I do not know if
there are good reasons to expect that such URIs will in fact be found
in the wild, and that clients will handle them as the draft suggests.
If there are no good reasons to expect both, then remove it wholesale.

>Section 4.3 already specifies that "crs" (and the new "u") parameter MUST
>NOT occur more than once each. I haven't added any text regarding the "too
>many digits" problem, and have been looking for similar text for other URI
>schemes - but haven't found any... I think that any options here would be
>contagious (eg. Allowing the client to drop URIs with "too many" digits,
>and recommending authors to not create such URIs?). Any advice appreciated.

At the least the draft should highlight that behavior for these cases
is left undefined by the specification, that would make it easier for
other reviewers to comment upon that, and implementers would not have
to search the draft for such rules.

>Section 4.5. contains text about encodings. Does it make sense to add the
>text there, or would you prefer an additional "Internationalization
>Considerations" section within section 4?

Adding it to 4.5. An I18N Considerations section would go alongside the
Security and IANA Considerations but the text would fit better into 4.5.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/