Re: [AVT] new I-D on temporal URI addresses

[Magnus Westerlund <magnus.westerlund@era.ericsson.se>]

Hi, Silvia.

I see the possibility of this proposal. However I have a number of 
comments on this proposal.

First is the possibility to specify this as a general mechanism. It 
seems that you want to have this to apply to all URI schemes. Is that 
really possible? How do you know that the use of @ will not collide with 
any usage? For example the rtsp scheme does not define how to interpret 
the fragment. So this is up to the server responding to a request. So 
this can potentially already be used by some implementations. Also does 
it make sense to be defined for all schemes. As this is currently 
related to media it seems that for the moment it applies to HTTP(S) and 
RTSP(U|S).

So a general question, what is the actually possibilities to standardize 
such a solution?

Second, is the usage of the fragment identifier. It seems that you tries 
to redefine the meaning of the fragment identifier. See below.

From RFC 2396:

 "When a URI reference is used to perform a retrieval action on the
  identified resource, the optional fragment identifier, separated from
  the URI by a crosshatch ("#") character, consists of additional
  reference information to be interpreted by the user agent after the
  retrieval action has been successfully completed.  As such, it is not
  part of a URI, but is often used in conjunction with a URI.

     fragment      = *uric

  The semantics of a fragment identifier is a property of the data
  resulting from a retrieval action, regardless of the type of URI used
  in the reference.  Therefore, the format and interpretation of
  fragment identifiers is dependent on the media type [RFC2046] of the
  retrieval result.  The character restrictions described in Section 2
  for URI also apply to the fragment in a URI-reference.  Individual
  media types may define additional restrictions or structure within
  the fragment for specifying different types of "partial views" that
  can be identified within that media type."

Two things strikes me as not being taken into account by your draft in 
relation to this quote. The first is from the first paragraph of the 
quote. The fragment identifier is interpreted by the user agent. While 
in chapter 4 of your draft you clearly specifies that the server shall 
interpret the fragment. This redefines the behavior of the fragment 
identifier.

Secondly the interpretation of the fragment identifier is in relation to 
the data resulting in the request. So in fact it seems that you need to 
define the behavior on per media basis.

I think the use of fragment to specify where in a media resource is 
appropriate in some case. For example an RTSP URL that has a fragment of 
the proposed type is useful. However as RTSP works the server shall not 
interpret the fragment as this is pointless. Only the client needs to do 
this and use that to determine the range to include in the PLAY request. 
So again the usage rules in chapter 4 seems to be wrong.

It seems that the time specification should be complemented to allow 
specifying ranges. The result of a search or the part of your friends 
wedding video that you want to point out would in most cases only be a 
part of the video. Therefore both a start and stop time seems useful. 
Then it is also a very short step to having multiple ranges allow one to 
point out multiple parts of the same resource that are interesting.

Also I think you have a few strange thing in the definition. First you 
specify an attribute "start" that I think are pointless. Either you 
totally skip the fragment or you can use "npt=0". Secondly it the 
defaulting to "npt". This clashed with the general parameters. If you 
use start then you have actually wrote "npt=start" which isn't defined. 
"now" works as long as this is based on the RTSP definitions of NPT, 
however from your BNF definitions this is evidently not the case. So my 
proposal is to skip having any default time scheme if you are going to 
have general attributes that does not belong to a time scheme.

If you would like the server to take the range into account would not 
the use of query (?) be better? However I hope that somebody that are 
more will versed in URIs can give further suggestions.

I can see the usefulness of this proposal, however there is need to 
resolve a number of issues:
- A general standardization or target certain URI schemes?
- Applicability on different media types and protocols needs to better 
understood.
- Use of fragment or other URI syntax element, like parameter or query?
- Need for having ranges?
- The actual need for general parameters?

Regards

Magnus Westerlund 
Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se



_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt