Subject: [Enum] Re: Richard Stasny's review of brandner-enum-tel

From: Lawrence Conroy <[email-masked]>
Date: Thu, 28 Feb 2002 16:09:08 +0000

Hi Richard, Folks,
   First, thanks for reading the draft.

Second...
*	The comment on ss 3 is good.
There are many ways that one could use tel: URIs within NAPTRs. Even
within the case of using NAPTRs for the 'tel' enumservice, there are a
number of uses.

What we said (in effect) was "The 'tel' enumservice indicates that the
constructed URI *will* have the scheme "tel:", and this can be used to
initiate a telephone call".

As you suggest, "What the President meant to say was:"
"The 'tel' enumservice indicates that the constructed URI *will* have
the scheme "tel:" and that this can be used to initiate a call using a
telephony service based on E.164 numbers natively. By implication, the
caller must already have a subscription to a service provider that
allows them access to such a service, or the result of processing with
this record should be ignored".

I like this re-phrasing, as it is more precise *and* more general. Much
appreciated.

Re. your further comments on this service, I'm still thinking about them
- it *is* complex.

*	The comments on ss4.1 is well taken.
As the (public) ENUM entries SHOULD be a full "global_phone_subscriber"
number (i.e. an E.164 number) there is no need to have a phone-context.

Adding a sentence to spell out SHOULD NOT use ";phone-context=" in case
of a "tel:" URI with a full E.164 number is fine. Will add.

BTW, I am a little concerned that we exclude 1-800 numbers that are
only "dialable" from a given region, if we make the E.164 number a MUST
which is why it's a SHOULD (and use of phone-context will be a SHOULD
NOT). I'm not sure if this is a problem, so would appreciate anyone's
comments on this.

*	Comments on ss4.2 (TSP parameter) - agreed(ish)
Agreed, it is very complex.
It is made more complex by not knowing where to introduce any such
"profile for use" issues. I think it should be in ENUM as it's an
operational feature for the whole system, so...
Please, gentle ADs and Co-Chairs, give "the benefit of the doubt"
to this thread.

Given that:
This TSP information can be sensitive, so I'm happy to change the SHOULD
to a MAY.
Is this OK with you, Rudi?

I do like the idea of using data in another part of the DNS forest to
hold prefix-dial strings is useful for prefix or "on-demand" carrier
selection, so I think that it's something I'd be loath to discourage.
(i.e. not lower than MAY, please :)

In terms of standardising the data format, this could WELL be another
tel: URI, using a local_phone_subscriber number with a global phone
context tag to indicate where the prefix can be used.
Thus I think that the following works: <tel:01134;phone-context=+43>.

The information could be held in a NAPTR record under the Operator's
".at." domain - that seems a useful way of storing it, and in a useful
place. If anyone has alternative proposals, please holler.

I *do* have a question on whether or not this NAPTR or URI needs a tag
to indicate that it's not a dialable number on its own. Any thoughts
on this will be gratefully received.

all the best,
    Lawrence

-- 
[email-masked]: +44 1794 833666::<my opinions>:

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Brandner Rudolf <[email-masked]>
Date: Thu, 28 Feb 2002 17:59:16 +0100

First I'd like to thank Richard Stastny for reviewing our draft and the comments he made.

Second, I'm happy with the Lawrence's answer.

Rudi

> -----Ursprüngliche Nachricht-----
> Von: Lawrence Conroy [mailto:[email-masked]]
> Gesendet: Donnerstag, 28. Februar 2002 17:09
> An: [email-masked]
> Cc: [email-masked]; Rudi
> Betreff: Re: Richard Stasny's review of brandner-enum-tel
> 
> 
> Hi Richard, Folks,