URI Requirements - version 2

Attached an update of the requirements document.

I included all comments but sometimes found it hard
to improve the wording. Suggestions for better wording
are highly appreciated.

I added a section to explain where Broadcast URI are for
and how they might be used. I hope that can help us 
to converge in our current discussions.

I consider this added section to be my answer 
on unanswered comments in the discussion.

To clarify a bit more, here is a description of what 
I think we have to specify wrt. URIs. It includes 
the suggestion by Kimmo to use URNs.

As I said before, I am neither expecting we will be able 
to define a single URI scheme which covers all the needs 
as expressed by the requirements. That's why I have 
no objections to solve for the TV channel first.
However, I keep repeating that that doesn't satisfy 
all our wishes.

I am thinking of the following scheme:

There is a URN scheme to identify TV Broadcast content.
Those URNs can be resolved into URLs, using some naming
service tbd. Depending on the context the URN resolves into 
- a URL for Internet access (http://......)
- a URL for TV Broadcast (where we are concerned about primarely)
- a URL for local storage/in-home (closely the same as the TV Broadcast
URL)

URLs and URNs are special cases of URIs.

Note that an application can choose to use TV Broadcast URLs
and not to use the URN.

As we don't have specified the TV Broadcast URL,
it might be interesting to see in what level the 
URN can map on the TV Broadcast URL, such that 
the naming service to resolve that mapping can 
be made efficient.

That's why I prefer not to forget about the corresponding 
requirements, even if we don't observe them at the start.


Warner.

--
Philips Research Labs. WY21 ++ New Media Systems & Applications
Prof. Holstlaan 4 ++ 5656 AA  Eindhoven ++ The Netherlands
Phone: +31 4027 44830
Fax:   +31 4027 44648    tenkate@natlab.research.philips.com