Re: [apps-discuss] WGLC: draft-ietf-appsawg-about-uri-scheme-03.txt

[Mykyta Yevstifeyev <[e-mail]>]

21 марта 2012 г. 1:58 пользователь Murray S. Kucherawy
<[e-mail]>написал:

> > -----Original Message-----
> > From: [e-mail] [mailto:
> [e-mail]] On Behalf Of Jiankang YAO
> > Sent: Monday, March 05, 2012 5:01 PM
> > To: [e-mail]
> > Cc: [e-mail]
> > Subject: [apps-discuss] WGLC: draft-ietf-appsawg-about-uri-scheme-03.txt
> >
> > Dear colleagues,
> >
> > This message starts a two-week WGLC on the draft draft-ietf-appsawg-
> > about-uri-scheme-03.txt.
> >
> > Please help to review this draft.  If you support publication, please
> > state as much on the list.  If you are opposed to publication, please
> > state that on the list as well.  It is more/only helpful if you give
> > your reasons for your position as part of your statement.
> >
> > Pls send your comments to [e-mail] or appsawg-
> > [e-mail] or editors.
> >
> > The WGLC will end on March 20, 2012 at 1:00 UTC.
>
> This is coming in a bit late, and apologies for that (and shame on me for
> complaining about other people who come in late on my drafts!), but the
> points should be easily resolved.
>
> [Relatively] Major Issues:
>
> In Section 4.2, you talk about the Intended Usage field of the
> registration being "what they must be resolved to, if resolvable."  Why
> would you allow registration of something that can't resolve to something?
>

This is what we had from the previous version of the document when we had
resolvable/unresolvable distinction.  We've dropped it, so I think I'll
drop these words as well.  (Actually, this document was originally written
"for" HTML5 'about' URIs, which are unresolvable, but later we reached an
agreement on not introducing this in the document.)


>
> Section 4.2 also talks about referencing a document that allows one to
> create an "interoperable" implementation of the "about" URI being
> registered.  I know we talked about this in the WG, but a new reader might
> well ask "interoperable with what?"  You might want to answer that question
> before the IESG asks it.  :-)
>

I believe this isn't an important matter.  "interoperable" is quite usual
term, and I don't think we need to detalize this.


>
> [Relatively] Minor Issues:
> I'm not so sure about use of RFC2119 language in the IANA Considerations
> section.  You're not really describing interoperability requirements with
> IANA.
>

I'll reply to a later message.


>
> [Absolutely] Nits:
> All of these are either reductions of overly-wordy text or fixes to minor
> grammar nits, or both.
>
> Section 1:
>
>        OLD
>                scheme, that is currently widely used by Web browsers and
> some other
>
>        NEW
>                scheme, which is currently widely used by Web browsers and
> some other
>
> Also, I'm not sure that "Web" is a proper noun, so it should probably be
> "web".
>

Fixed.


>
>        OLD
>                The concept of "about" URIs has been formed at the times
> when the
>                applications did not have the "friendly" user interface, in
> order to
>                provide an access to the aforementioned resources via
> typing the URIs
>                in the address bar.  Even though the user interface of
> current
>                Internet-targeted software effectively rescinds the issue,
> and
>                "about" URIs can be thought to be a rudimentary phenomenon,
> they are
>                still supported by a variety of Web browsers and are not
> going to cease
>                to exist.
>
>                As use of "about" URIs has been quiet long-lasting, and the
> URIs have
>                been used without any proper registration and absent any
> proper
>                specification, the necessity for the latter two actions
> arises.
>                The purpose of this document is to provide a stable
> specification for
>                "about" URI scheme and correspondingly register it in the
> IANA
>                registry.  Along, several provisions for handling the
> "about" URIs
>                Are set.
>
>        NEW
>                The concept of "about" URIs formed when applications did
> not have a
>                "friendly" user interface, to enable access to the
> aforementioned
>                resources by typing URIs into an address bar or similar
> feature.
>                They have however become commonplace in modern user
> applications.
>
>                Given their current ubiquity, their absence from the URI
> scheme
>                registry and lack of a defining document is conspicuous.
>  Therefore,
>                this document provides a stable specification for the
> "about"
>                URI scheme and registers it with IANA.
>

Quite agree with this text.


>
> Section 2.2:
>
>        OLD
>
>                Generally speaking, the resource a particular "about" URI
> resolves to
>                is denoted by <about-token> part of the URI, and
> <about-query>
>                specifies additional information concerning its handling
> and/or the
>                information that should be returned in the resource a URI
> is resolved
>                to.
>
>                However, it is impossible to specify binding between all
> the possible
>                tokens and the semantics of "about" URIs that would contain
> such
>                tokens, which this document does not attempt to do.
>  Therefore, any
>                application resolving an "about" URI MAY choose the
> resource it is
>                resolved to at its own discretion, with the exception of
> those
>                defined below as 'special-purpose "about" URIs'.  They MAY
> use
>                internal redirection to accomplish this (for instance, Opera
>                redirects all "about" URIs except "about:blank" to its
> internal
>                "opera" URIs).
>
>        NEW
>
>                Generally speaking, the resource to which a particular
> "about" URI resolves
>                is denoted by <about-token> part of the URI, and
> <about-query>
>                specifies additional information concerning its handling
> and/or the
>                information that should be returned in the resource to
> which the URI
>                resolves.
>
>                However, it is impossible to specify a binding between all
> the possible
>                tokens and the semantics of "about" URIs that would contain
> such
>                tokens.  Therefore, the resource referenced by the URI is
>                application-specific, except for those listed below as
> 'special-purpose
>                "about" URIs'.  Applications MAY use internal redirection
> to accomplish
>                this (for instance, the Opera web browser redirects all
> "about" URIs except
>                "about:blank" to its internal "opera" URIs).
>

Changed.


>
> Section 2.2.1:
>
>        OLD
>
>                A small, though expandable, range of <about-token>s are
> reserved for
>                special purposes ("special-purpose tokens").
>
>        NEW
>
>                A small, though extensible, range of <about-token>s is
> reserved for
>                Special purposes ("special-purpose tokens").
>
>        OLD
>
>                Additional special-purpose tokens can be defined by
> registering an
>                registry created in Section 4.2. Special-purpose "about"
> URIs are
>                intended to be uncommon, and new ones should be defined
> only when
>                there is a need to strongly connect a particular
> <about-token> with a
>                particular function in all applications.
>
>        NEW
>
>                Additional special-purpose tokens can be defined by
> updating the
>                registry created in Section 4.2. Special-purpose "about"
> URIs are
>                intended to be uncommon, and new ones only need to be
> defined when
>                there is a need to strongly connect a particular
> <about-token> with a
>                particular function in all applications.
>

Taken into account.


>
> Section 3:
>
>        OLD
>
>                Generic security considerations for URIs are discussed in
> Section 7
>                of RFC 3986 [RFC3986].  However, many of those provisions
> hardly
>                apply to "about" URI scheme, as they are mainly scoped to
> schemes
>                used in the Internet, not internally.
>
>                "about" URIs may sometimes refer to a sensitive
> information, such as
>                user passwords stored in a cache, or parameter that, if
> changed, may
>                affect user's data.  The application should therefore
> ensure that
>                user's data is in the safety, and no threats are imposed by
> "about"
>                URIs.
>
>        NEW
>
>                Generic security considerations for URIs are discussed in
> Section 7
>                of RFC 3986 [RFC3986].  However, few of those provisions
>                apply to the "about" URI scheme, as they are mainly scoped
> to schemes
>                used in the Internet, not internally.
>
>                "about" URIs can sometimes refer to a sensitive
> information, such as
>                user passwords stored in a cache, or parameters that, if
> changed, could
>                affect user's data.  The application therefore needs to
> ensure that
>                the user's data is secured, and no threats are imposed by
> "about"
>                URIs.
>
> Section 4.2:
>
>        OLD
>
>                o Intended usage:  A short description of how "about" URIs
> with the
>                  registered token must be handled; especially, what they
> must be
>                  resolved to, if resolvable.
>
>                o Handling query component:  It should be mentioned whether
> there are
>                  some provisions on handling query components in the
> "about" URIs
>                  with the registered token.
>
>                o Contact/Change controller:  An individual or an
> organization which
>                  (1) should be contacted for more details, and (2) is
> authorized to
>                  change the registration.
>
>                o Specification.  This provides documentation at a level
> that could
>                  be used to create a compliant, interoperable
> implementation of the
>                  registered "about" URI.  The reference to a full
> specification MUST
>                  be provided here, and there should be a reasonable
> expectation that
>                  the documentation will remain available.  IANA will
> consult with
>                  the IESG or its specified delegate if there is doubt
> about whether
>                  the specification is adequate for the purpose.
>
>                The following is a template for "blank" token:
>
>        NEW
>                o Intended usage:  A short description of how "about" URIs
> with the
>                  registered token must be handled; especially, to what
> resource
>                  they are to resolve.
>
>                o Handling query component:  Describe any requirements for
> handling
>                query components in "about" URIs that contain the registered
>                  token.
>
>                o Contact/Change controller:  An individual or an
> organization that
>                  (1) should be contacted for more details, and (2) is
> authorized to
>                  change the registration.
>
>                o Specification.  A permanent reference to a specification
> that can
>                  be used to create a compliant, interoperable
> implementation of the
>                  registered "about" URI.  IANA will consult with
>                  the IESG or its specified delegate if there is doubt
> about whether
>                  the specification is adequate for this purpose.
>
>                The following is a template for the "blank" token:
>

Accepted.

Thanks you for your assistance.

Mykyta Yevstifeyev


>
> -MSK
> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>