gmane.ietf.uri-review

Re: In WG last call review of URI Schemes rtsp, rtsps and rtspu

Martin J. Dürst — 2012-05-11T06:14:39


On 2012/05/11 2:44, Roy T. Fielding wrote:


I agree that "current contexts" is the wrong wording. What about 
something like:
"Therefore, at the time of publication of this document, fragment 
identifiers are meaningless in current email contexts."

Regards,   Martin.

Re: In WG last call review of URI Schemes rtsp,rtsps and rtspu

Roy T. Fielding — 2012-05-10T17:44:21


I wouldn't object, but I personally don't like talking about
"current contexts" in a spec that will live for decades.
I don't see why it matters -- if it is meaningless, nobody
will use them; if they use them, they won't be meaningless.

....Roy

Re: In WG last call review of URI Schemes rtsp, rtsps and rtspu

Ted Hardie — 2012-05-09T14:21:28

On Tue, May 8, 2012 at 9:28 PM, Roy T. Fielding <fielding< at >gbiv.com>
wrote, quoting Graham Klyne:


Would you still object if it simply said "Therefor fragment
identifiers are meaningless in current email contexts."?  I think this
remains useful and it eliminates the normative language.

regards,

Ted

Re: In WG last call review of URI Schemes rtsp, rtsps and rtspu

Martin J. Dürst — 2012-05-09T05:41:05


Thanks, fixed in my internal copy.

Regards,    Martin.
_______________________________________________
Uri-review mailing list
Uri-review< at >ietf.org
https://www.ietf.org/mailman/listinfo/uri-review

Re: In WG last call review of URI Schemes rtsp,rtsps and rtspu

Roy T. Fielding — 2012-05-09T04:28:56

The second to last sentence is wrong.  That spec cannot make
normative requirements about something that is out of scope;
any fragment is completely outside the scope of a URI scheme
specification.  Just remove the "Therefore, ... resolution."
sentence -- it serves no useful purpose.

....Roy

Re: In WG last call review of URI Schemes rtsp, rtsps and rtspu

Martin J. Dürst — 2012-05-09T01:42:28

This is what both http://tools.ietf.org/html/rfc6068 ("The 'mailto' URI 
Scheme") and http://tools.ietf.org/html/draft-duerst-eai-mailto-03 (an 
update to include EAI) currently say on this topic:

    Note that this specification, like any URI scheme specification, does
    not define syntax or meaning of a fragment identifier (see [STD66]),
    because these depend on the type of a retrieved representation.  In
    the currently known usage scenarios, a 'mailto' URI cannot be used to
    retrieve such representations.  Therefore, fragment identifiers are
    meaningless, SHOULD NOT be used on 'mailto' URIs, and SHOULD be
    ignored upon resolution.  The character "#" in <hfvalue>s MUST be
    escaped as %23.

This seems to be fully in line with the discussion up to here, including 
Roy's comment above, but if anybody thinks it needs to be changed, 
please send some new proposed wording.

Taking the above text, and adopting it for the rtsp situation, might 
lead to something like:

    Note that this spec

Re: In WG last call review of URI Schemes rtsp, rtsps and rtspu

Ted Hardie — 2012-05-08T20:56:21

In the context of registration, I personally believe that a definition
of how a scheme is expected to be used is sensible.  In that context,
stating whether or not you'd expect to see fragments in the given
usage would be appropriate, provided it doesn't contradict the core
spec.  At a base level, the core spec says that fragments allow you to
identify secondary resources related to the main resource; if that's
not expected because of the semantics of the scheme, I think it's
useful to say so.

regards,

Ted Hardie

Re: In WG last call review of URI Schemes rtsp,rtsps and rtspu

Roy T. Fielding — 2012-05-08T18:36:24

No, fragments have nothing to do with the definition of schemes.
They occasionally have something to do with how schemes are used,
such as

   mailto:ted.ietf< at >gmail.com#subject

could be used, for example, to refer to either the owner of that mailbox
or to opening an email entry form with "ted.ietf< at >gmail.com" pre-filled
in the To field and the active cursor placed in an input field named
subject.  We don't know its true definition, if any, until someone
builds a system that happens to use the identifier in that fashion.

....Roy

Re: In WG last call review of URI Schemes rtsp, rtsps and rtspu

Ted Hardie — 2012-05-08T17:55:57

Well, perhaps a less theoretical distinction would be whether or not
what a URI is associated can have a media type.  A media type for
mailto:ted.ietf< at >gmail.com is
not really sensible; a fragment for that identifier is thus not sensible.

Ted

/who is not yet a sequence of octets

Re: In WG last call review of URI Schemes rtsp, rtsps and rtspu

Julian Reschke — 2012-05-08T17:47:15

A URI has an associated resource *by definition*.

The interesting question is whether there's a way to retrieve a sequence 
of octets describing it...

Re: In WG last call review of URI Schemes rtsp, rtsps and rtspu

Larry Masinter — 2012-05-08T17:14:06

Note that the URNbis working group has been discussing fragment identifiers for URNs.
If you say a URN is merely a URI using the "urn:" scheme, then perhaps whether
URNs allow fragment identifiers should be out of scope for the URNbis working group.

Larry


-----Original Message-----
From: Ted Hardie [mailto:ted.ietf< at >gmail.com] 
Sent: Tuesday, May 08, 2012 10:11 AM
To: julian.reschke< at >gmx.de
Cc: Magnus Westerlund; Larry Masinter; mmusic-chairs< at >tools.ietf.org; uri-review< at >ietf.org
Subject: Re: [Uri-review] In WG last call review of URI Schemes rtsp, rtsps and rtspu

On Tue, May 8, 2012 at 3:15 AM, Julian Reschke <julian.reschke< at >gmx.de> wrote:


I'm not sure I agree with this.  If a registration is intended to
create an identifier that has no associated resource (and thus no
media type), it could say that fragments are not permitted.  This is a
restatement of something that can be inferred from 3986, but I think
it's a useful thing to reinforce.

regards,

Ted

Re: In WG last call review of URI Schemes rtsp, rtsps and rtspu

Ted Hardie — 2012-05-08T17:11:22


I'm not sure I agree with this.  If a registration is intended to
create an identifier that has no associated resource (and thus no
media type), it could say that fragments are not permitted.  This is a
restatement of something that can be inferred from 3986, but I think
it's a useful thing to reinforce.

regards,

Ted

Re: draft-farrell-decade-ni

Graham Klyne — 2012-05-08T12:12:28

Not quite: my original response suggested an application of this structure which 
might have useful meaning.  It's just your example that is not given a defined 
meaning by the ni: spec.

I think it's pretty clear which hierarchical operations have defined meaning: 
apply the resolution rule and see if the result has defined meaning per the 
spec.  (I suppose one might add a warning:  "Injudicious resolution of relative 
URI references with respect to an ni: base URI may yield an ni: URI whose 
interpretation is not defined by this specification.")

...

(I feel that I'm spending more time on this than the issue deserves.  I don't 
feel especially strongly that the scheme should be hierarchical or not, and 
hierarchical seems OK to me.  I mainly feel it's not worth changing a spec that 
others have thought about more deeply than I without a compelling reason.)

#g
--

Re: In WG last call review of URI Schemes rtsp, rtsps and rtspu

Julian Reschke — 2012-05-08T12:14:32

+0.5.

I agree that what the spec does isn't wrong; it's just a bit misleading 
in that it implies that a URI scheme definition has *any* authority over 
the fragment identifier.


As Larry just mentioned: <http://www.w3.org/TR/media-frags/>

Best regards, Julian

Re: In WG last call review of URI Schemes rtsp, rtsps and rtspu

Larry Masinter — 2012-05-08T12:05:00

side note that w3c media fragments working group has proposed rec covering using fragments for temporal media, which i think is relevant ...mmusic should review asap.

Connected by DROID on Verizon Wireless

-----Original message-----
From: Magnus Westerlund <magnus.westerlund< at >ericsson.com>
To: "julian.reschke< at >gmx.de" <julian.reschke< at >gmx.de>
Cc: Larry Masinter <masinter< at >adobe.com>, Ted Hardie <ted.ietf< at >gmail.com>, "mmusic-chairs< at >tools.ietf.org" <mmusic-chairs< at >tools.ietf.org>, "uri-review< at >ietf.org" <uri-review< at >ietf.org>
Sent: Tue, May 8, 2012 11:48:16 GMT+00:00
Subject: Re: [Uri-review] In WG last call review of URI Schemes rtsp, rtsps and rtspu

On 2012-05-08 12:15, Julian Reschke wrote:

But, then what I have done isn't wrong either as I haven't override the
rules for fragment, only made it clear how they interface with the URI
definition. From my perspective I can remove the fragment syntax
definition, but I would instead at least explicitly call out that
fragments may occur following RF

Re: In WG last call review of URI Schemes rtsp, rtsps and rtspu

Magnus Westerlund — 2012-05-08T11:48:07

But, then what I have done isn't wrong either as I haven't override the
rules for fragment, only made it clear how they interface with the URI
definition. From my perspective I can remove the fragment syntax
definition, but I would instead at least explicitly call out that
fragments may occur following RFC 3986 syntax. Personally I don't see
that as being better.

Secondly, when we are on this topic. Can someone answer how you
determine the media type for an rtsp URI? RTSP URI points to resources
that can provide controlled playback of the resource using any number of
media types in form of RTP payloads formats depending on what is
suitable for the resource. In fact from issuing an PLAY request on an
audio only resource you still can receive a media stream where the
format it is encoded my actually change during the playback operation.

To be clear I don't plan to define a fragment handling format for RTSP
URIs, but there has been discussion in the past the desire has been to
do something that is media form

Re: In WG last call review of URI Schemes rtsp, rtsps and rtspu

Julian Reschke — 2012-05-08T10:15:13

It's pointless, as a URI scheme definition can't override RFC 3986, and 
parsing of scheme name and fragment are already defined by RFC 3986.

Optimally, a new scheme definition just defines the scheme-specific part.


No.


Exactly :-)

Best regards, Julian

Re: In WG last call review of URI Schemes rtsp, rtsps and rtspu

Magnus Westerlund — 2012-05-08T09:45:18

Larry,

Can you please clarify something for me. What I have done is that I have
made it clear in the URI syntax that the fragment ABNF construct from
RFC 3986 MAY occur in an valid rtsp URI syntax. Are you saying that this
is not the right thing to do? How could I then indicate the appropriate
syntax  when the fragment identifier occur with the URI scheme being
defined? Can't I even say that fragments is not allowed for a scheme?
This appear to be the case if one would implicitly define the fragment
in an URI scheme.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund< at >ericsson.com
----------------------------------------------------------------------

Re: draft-farrell-decade-ni

Eric Johnson — 2012-05-08T09:06:06

Hi Graham,

On 5/7/12 10:38 PM, Graham Klyne wrote:

Taking your point, perhaps at a minimum the proposal should document 
which hierarchical operations will yield a result with "a defined 
meaning according to the rules of the ni: scheme", and which ones won't. 
Especially so since the proposed scheme uses the "//" indicator which 
implies hierarchical operations, and we've already agreed that some such 
operations are meaningless.

Even simpler, though, would be to change the syntax to remove the 
indication of hierarchical syntax, since, as I understand it, *none* of 
the hierarchical operations possible will yield a useful result "having 
a defined meaning according to the rules of the ni: scheme." (Well, OK, 
some might have a defined result, but only in the sheer-dumb-luck sense 
that an infinite # of typing monkeys in an infinite time would 
eventually produce the works of Shakespeare.) But maybe I've 
misunderstood the proposal?

-Eric.

Re: draft-farrell-decade-ni

Graham Klyne — 2012-05-07T20:38:06

It's a simple consequence of applying the resolution rules in RFC 3986.  That's 
all I claimed.


Oh, it's a perfectly valid URI according to the rules of RFC3986, just not 
having a defined meaning according to the rules of the ni: scheme.  I don't 
think it's the task of a specification, or even possible, to catch and somehow 
prohibit every clueless operation that might be attempted.


I'm not seeing the harm here.

#g
--

Re: the "ni:" URI scheme soon to "last call" in IETF -- security concern

Larry Masinter — 2012-05-08T00:51:09

Since I'm quoted, I thought I better clarify:

"Persistence" and "Permanently" are acts of intention -- a name is "persistent" or "permanent" if there is a credible SLA by some current and future resolution service, where the service promises to be the authority (forever) for telling everyone what a name means or identifies.

The "ni:" scheme does not provide a persistent name for anything other than chunks of data.

I suppose I should send in an IPR disclosure
http://www.google.com/patents/US5742807
(assigned to Xerox).