21.04.2011 20:36, 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
Hello,

I have some other minor comments to this URI scheme registration.  First 
of all, +1 to almost all comments from Björn Höhrmann.  I fully agree 
with all the issues he raised, except the one - see below.

Now, some remarks to Section 4.3 of this document.


> 4.3. Registration of "ab" URI Scheme
>
>
>     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.
>     URI scheme name:  ab
>
>     Status:  Permanent
>
>     URI scheme syntax:
>         paburi = "ab:" addrbook [ "?" extensions ]
>         addrbook = segment
>              ;<segment>  defined in [RFC3986]
>         extensions = query
>              ;<query>  defined in [RFC3986]
I understand this is defined with ABNF.  Your document in Section 1.1 
mentions this, but I think mentioning this issue once more in the 
template wouldn't be harmful, as I propose below.

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 "*pab*uri".  
If you decide to change the scheme name per comments from Björn, this 
rule should also be corrected.
>     URI scheme semantics:  "ab" URIs are used for designating references
>         to address books.  An address book is an internal concept used by
>         different applications (such as Sieve interpreters) for
>         describing a list of named entries, and may be translated into
>         other types of address books, such as LDAP Groups.  Address books
>         may be private or shared; they may be personal, organizational,
>         or perhaps even "crowdsourced".
This section should also have some words about the role of <addrbook> 
and <extensions> parts in the URI.
>     Encoding considerations:  Percent-encoding is allowed in "segment"
>         and "query" components.  Internationalization is handled by IRI
>         processing.
I see this is already commented by Björn.
>     Intended usage:  An "ab" URI is designed to be used internally by
>         applications for referencing address books.  Each URI is intended
>         to represent a grouping of addresses that can be logically
>         thought of as one "book".  Any given address can belong to more
>         than one book -- that is, can be referred to by more than one
>         URI.
> [ . . . ]
>
>     Applications and/or protocols that use this URI scheme name:
>         Currently only the Sieve External List extension is using this
>         URI scheme.  Email clients that use URIs internally might find
>         this URI scheme to be useful as well.
>
>     Interoperability considerations:  Applications are only REQUIRED to
>         support "ab:default".
I cannot find any distinctive description of this reserved URI, 
information about what it is used for.  Having at least sentence dealing 
with this issue would be OK, I think.
>     Security considerations:  Applications SHOULD ensure appropriate
>         restrictions are in place to protect sensitive information that
>         might be revealed by "ab" URIs from access or modification by
>         untrusted sources.
I do not see anything regarding the URI scheme in your section 3.  While 
it concerns the proposed extension, some words specifically about the 
URI scheme won't be redundant, IMO.
>     Relevant publications:  this RFC
>
>     Contact:  Sieve mailing list<sieve@ietf.org>
Shouldn't this be "Sieve WG <sieve@ietf.org>".  Maybe the same is below 
- it should be just IESG, shouldn't it?

>     Author/Change controller:  IETF/IESG
Now,

21.04.2011 21:54, Bjoern Hoehrmann wrote:
> I think at the beginning of 4.3 you need to have some background infor-
> mation about the scheme that makes sense to people who have never ever
> heard of SIEVE, addressing the questions above (one or two short para-
> graphs should suffice).
I do not think such information should go at the beginning of Section 
4.3.  This section is aimed just to provide IANA guidelines for 
registration.  Having it is a good idea, but somewhere else, eg. in 
Section 2.5.

Thanks for considering my comments in advance.

Mykyta Yevstifeyev


> We would like to get uri-review comments on the proposed scheme.
> There's a reference to the scheme in section 2.5, it's used in the
> examples in section 2.8.1 and at the end of the Security
> Considerations (section 3), and it's defined and registered in section
> 4.3.
>
> Thanks in advance for reviews and comments.
>
> Barry
> _______________________________________________
> Uri-review mailing list
> Uri-review@ietf.org
> https://www.ietf.org/mailman/listinfo/uri-review
>