|
|
Thanks for the quick response, but I think you have me mistaken for someone
else ;)
I am of the mind that 255 purpose codes should be enough; lists of URIs could
help in that. One thing that might be worth considering is that different URIs
may represent services with different capabilities - having multiple options
might help there. That might not apply for emergency, but if you are talking a
general solution, why not include the option? Maybe others can add weight to
one argument or the other.
With regards to the <provided-by>, the PIDF-LO soon-RFC says that content needs
to be registered with IANA. Currently URI-style content is not an option;
there is only the NENA definition (incidentally, this is broken, because a tel:
URI of only 10 characters isn't much use). This would suggest that to include
a URI you need to define a registered format, probably with schema. Also, the
format that you describe is something like a URN, but did you intend to
formalize this definition? Or, merely have it as an informal indicator (which
I think is your intention). Any complexity might depend on what people want to
use this information for; I wouldn't want to suggest that you are naÃve, but
maybe there are more uses than that.
By the way, this starts to blur the line between ECRIT and GEOPRIV.
When I talk about PSAP vs. ESRP vs. ESGW URIs I am actually talking about the
same sort of policy that you are talking about. That is, the decision of the
emergency operator to provide a useful URI, regardless of the type of entity
that actually gets routed to. I just don't see where knowing the difference is
of benefit to anyone. Why can't we just have one emergency URI?
I believe that an emergency operator uses an ESRP and ESGW in the same way that
they use emergency@xxxxxxxxxxxxx rather than operator.jane@xxxxxxxxxxxxx; I
don't think that this is oversimplification, but I would be willing to consider
reasons why someone (anyone) would want to know the difference.
BTW, I think you meant to say something more here (on ESGW and ESRP URIs):
> This is something that might be important to the end user, but might be
> important to the operator - in that
Ta,
Martin
-----Original Message-----
From: James M. Polk [mailto:jmpolk@xxxxxxxxx]
Sent: Thursday, 15 September 2005 11:08 AM
To: Thomson, Martin; ecrit@xxxxxxxx
Subject: Re: draft-polk-dhc-uri-00: mixed goals
At 07:31 PM 9/14/2005 -0500, Thomson, Martin wrote:
>To put this into perspective, I like the idea of this draft - I can see
>how this would be beneficial,
Thank you
>but I have a few questions.
don't you always?
;-)
> From a high level, when you look at the abstract, the draft talks about
> URIs - no specific topic.
yep
> So this draft has the potential to cover a wide array of URI-type
> configuration information.
yep
>All present URIs are mapping or emergency based, obviously driven by need.
yep
>Is this draft intended to be a container for future URI-type configuration
>information?
yep
>If this is going to be a container, why then use up numbers so rapidly
>with primary and secondary options?
How many URIs do you feel qualify as configuration information?
I hope not 255, but I could be wrong - as I've already received a comment I
should make the purpose byte 2 bytes long.
I know there will be resistance in the DHC community to overloading their
servers with that many URIs, so I thought I'd leave it at 1 byte in length
(255 possible URI types) until someone from that WG told me to up it).
>Why not provide a list in each option, similar to the way that RFC 3361
>and RFC 3397 provide a list of domain names? That would enable the
>provision of more than two fallback values if necessary - keeping in mind
>Michael's point that we already have means of fallback at other layers.
yeah - this is why I don't know if we need to address more than two URIs
for PSAPs, as the network, if designed right, ought to route around
problems. I mean, it's not like a URI is the same as an IP address.
www.google.com has many ways to it through many IP addresses.
>The rest of my comments are more specific to the contents of the document...
>
>The "provided-by" URI is probably better than the structure in PIDF-LO,
>but how do you envisage this working?
I see, for example, both Option 123 and this doc's Option in the
Request/Response from the server to bind the two, with the purpose=6 (Org
owning the Location) being exactly what is put into the <provided-by>
element within the PIDF-LO. This solves that nasty little discussion we all
had for about a year in "how do we learn this URL for 3825 and the civic
Option?" If they are in the same DHCP message, that ought to be a good
enough bind to Mr White-hat to allow troubleshooting of bad location
information after-the-fact.
>The <provided-by> element is currently underspecified, so an example might
>be useful here.
I am cautious of putting that in the DHC doc, and want that in another Arch
doc where the scemantics can be layed out within the context we
want. Maybe I'm being overly sensitive to the DHC WG not caring about
these specific URIs and getting hammered with all our messages back and
forth clarifying this or that.
But I can be talked into adding this type of example for each purpose value
into this doc if folks want that.
>Is this URI something that is included in the PIDF-LO directly?
yep - and that ought to go into one of ECRIT's docs
>If so, do you want to register a URN and schema for the <provided-by>
>contents?
Not sure on this - but I really had something like www.cisco.com/richardson
in mind for this, denoting Cisco was the company that gave out the location
info, and it was out of their Richardson (in this case Texas) office. I
thought this should give enough info to whomever to do the troubleshooting.
I really hadn't thought it needed to be much more complicated than
that. Maybe I'm being naive.
>OR is the intent of this URI that the endpoint dereferences the URI and
>retrieves an XML fragment containing the <provided-by> contents? In which
>case do you expect that application/xml is sufficient as a MIME-type?
>
>I think that from a user perspective the ESRP and PSAP should appear to be
>the same entity.
This could be a policy area in which only one is returned to the client. We
can make that semantic clear in an ECRIT Arch/BCP type doc. Something like:
"If the client asks for a PSAP URI, and gets back a ESRP URI, it MUST be
satisfied with that URI and treat it the same."
>This is really a question of degree: do I want the SIP URI for an
>individual PSAP operator?
Again - this is a policy decision I didn't want this doc to deal with, so I
put in both (and one backup)
>For instance, emergency@xxxxxxxxxxxxx should be enough - I don't care what
>is done beyond this point. I assume that contacting
>emergency@xxxxxxxxxxxxx will get me help.
I agree
>Distinguishing between an ESGW and ESRP is even less useful - I would hope
>that they all appear the same to the end user.
This is something that might be important to the end user, but might be
important to the operator - in that
>I think that we should also mandate that a mapping service use a PIDF-LO
>as input, therefore distinguishing between a civic and geo mapping service
>does not add any value.
Andy Newton asked for these, and he can give more justification for them
(I've slept since he talked me into adding them).
>The capabilities of the mapping service (the ability to accept civic or
>geo input) are metadata.
>
>Cheers,
>Martin
<snip ugly disclaimer>
cheers,
James
*******************
Truth is not to be argued... it is to be presented.
------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.
If you have received it in error, please notify the sender
immediately and delete the original. Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]_______________________________________________
Ecrit mailing list
Ecrit@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ecrit
|
|