Re: [Uri-review] Request for review of "ab:" URI scheme

[Mykyta Yevstifeyev <[e-mail]>]

22.04.2011 18:35, Barry Leiba wrote:
>>> In the Sieve working group, draft-ietf-sieve-external-lists defines an
>>> address-book URI scheme, "ab:".  See the draft, here:
>>> http://tools.ietf.org/html/draft-ietf-sieve-external-lists
> In response to comments by Bjoern and Mykyta, I have changed the
> scheme to "addrbook".  Apart from that change, I've made the following
> other changes to the draft.  If these satisfy the concerns, I will get
> approval from the working group, and we'll proceed with sending the
> document to the IESG.
I think these proposed changes almost fully cover those concerns I 
pointed to.  However see some remarks in-line.  (I also think Bjoern's 
comments are also considered here, but let's wait for his personal 
response).
> Barry
>
> ===============================================
> In Introduction, section 1:
> OLD
> <     The "ab" URI scheme (in particular, the URI "ab:default"), defined in
> <     Section 4.3 MUST be supported.  The mandatory-to-implement URI "ab:
> <     default" gives access to the user's default address book (usually the
> <     user's personal address book).
> NEW
>>     The "addrbook" URI scheme (in particular, the reserved URI "addrbook:
>>     default"), defined in Section 4.3 MUST be supported.  The mandatory-
>>     to-implement URI "addrbook:default" gives access to the user's
>>     default address book (usually the user's personal address book).
>>     Note that these are URIs, subject to normal URI encoding rules,
>>     including percent-encoding.
Shouldn't the reference to RFC 3986 go here?
> [ . . . ]
>
> In "URI scheme semantics:" in section 4.3:
> NEW
>>         The address book name (the "addrbook" element in the ABNF above)
>>         refers to a specifically named address book, as defined by the
>>         implementation.  A user might, for example, have access to a
>>         number of different address books, such as a personal one, a
>>         family one, a company one, and one for the town where the user
>>         lives.
>>
>>         The extension information (the "extensions" element in the ABNF
>>         above) is available for use in future extensions.  It might allow
>>         for things such as dynamic subsets of an address book (for
>>         example, "addrbook:personal?name.contains=fred").  There are no
>>         extensions defined at this time.
I think some words about how these extensions are specified would be 
relevant.
> [ . . . ]
> ===============================================
All other changes, as mentioned below, are OK.  I'd also like to ask 
about some of my comments not included above:

> >  You can also add something like "The "ab" URI takes the form of<paburi>
> >  rule below, defined using ABNF [RFC5234]."  I also do not understand why the
> >  scheme name is "ab" whereas the rule is "paburi".  If you decide to change
> >  the scheme name per comments from Björn, this rule should also be corrected.
> The names of the ABNF elements aren't related to the text strings that
> they produce.  There's no reason for any change here.
>
Anyway, <paburi> rule will make the reader a bit confused.  The 
<addrbook-uri> or <addrbookuri> would obviously be more appropriate here.

>     The following requests IANA to register a new URI scheme according to
> >      the IANA registration template specified in [RFC4395]:
> >
> >  I see RFC 4395 is normative reference here.  I do not think reading this
> >  document should be compulsory for understanding your document.  Maybe
> >  Informative reference is more appropriate here.
> Clearly not; see below.
>
I did not find anything related to this issue "below".

> Huh?  I don't understand what you're getting at.  The contact
> information is correct, and isn't related to who has change control
> (the IESG).
The "Contact", according to RFC 4395 is:

>   Person (including contact information) to contact for further
>        information.
(Organizations are also permitted).

The mailing list cannot be 'Contact'.

Mykyta Yevstifeyev
> _______________________________________________
> Uri-review mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uri-review
>