Subject: [Enum] SchemaSet strawman

From: Lawrence Conroy <[email-masked]>
Date: Sun, 26 May 2002 15:32:04 +0100

Hi folks,
  as promised... summary of the outline schemas.
I'll describe the URI-schemes to go with these in another post.

Andrew suggests:
talk -- intention is to engage in an interactive telephony communication
srs/inquire/(enquire) -- intention is to act as a service resolution service
deliver -- intention is to deliver a message (deposit a page or 
snippet of media)
chat -- intention is to engage in a session-oriented text exchange
video or see - [I'm not clear about this one - clarification?]
share -- intention is to engage in workflow or whiteboard

Clive suggests 'texttalk' instead of chat, to allow tdd phone usage.

 From some other discussions I had in mind:
talk/phone -- interactive telephony communication here (Note that 
this doesn't mean exclusively audio - it could be videotelephony)
srs -- intention is to act as a service resolution service (e.g. sip: 
or maybe ldap:)
message -- intention is to deliver a message (this could be SMS, or 
fax, or email of its many kinds, or non-session oriented IM, or ..)
streaming -- intention is that there is a streaming resource here 
(e.g. rtsp:). Note that a streaming service is not bi-directional. 
Thus it differs from the interactive telephony service implied by 
'talk'
file/info -- intention is that there is a resource here to get 
information (e.g. http:, https:, ftp:, ...)
...

Patrik suggests:
'sip' -- I think this has the same goal as the existing sip-e164 
draft, modulo syntax changes to fit with 2916bis. It is similar to 
the 'srs' function.

'voice' -- I think that this is similar to the 'talk' function 
described above, but seems to specify that the result will be voice 
only (i.e. not video & voice) and it might also allow VPIM messages - 
I hope not, but this would need to be clarified.

Rich suggests that a registrant should be able to provide a NAPTR 
without specifying the capabilities or preference policies associated 
with a resource identified within the (global) DNS.

Thus, given that there is at least one enumservice sub-field in each NAPTR,
I'd suggest that we add an "any" enumservice ("unspecified" works 
too, but "any" is shorter :). In this way, a NAPTR with this 
enumservice does not expose its applicability to DNS requesters.

Also, given that there may be more than one enumservice sub-field 
within a single NAPTR (and given that this may be abnormal), the 
presence of "any" together with one or more other enumservices within 
a single NAPTR means that it can be considered not only for the other 
specified functions, but for all functions - if the registrant does 
not wish to specify anything further, I'd suggest that then any other 
enumservice sub-fields present should be ignored.
Although this seems to be a bizarre usage (having "any" plus some 
specific enumservice), I think it MAY be used in some obscure 
non-terminal processing cases. Any clarification here would be 
greatly appreciated.

As an aside, this point on privacy is well taken. Any definition of 
"tel:" URI parameter "svc" as proposed by Richard should specify 
"svc=any" as an acceptable value; of course, in this case one may 
choose not to insert the URI parameter at all.

additions/mods/outrage welcomed.

all the best,
   Lawrence
-- 
[email-masked]: +44 1794 833666::<my opinions>:

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

---

From: Richard Shockey <[email-masked]>
Date: Sun, 26 May 2002 11:39:23 -0400

>talk/phone -- interactive telephony communication here (Note that this 
>doesn't mean exclusively audio - it could be videotelephony)
>srs -- intention is to act as a service resolution service (e.g. sip: or 
>maybe ldap:)
>message -- intention is to deliver a message (this could be SMS, or fax, 
>or email of its many kinds, or non-session oriented IM, or ..)
>streaming -- intention is that there is a streaming resource here (e.g. 
>rtsp:). Note that a streaming service is not bi-directional. Thus it 
>differs from the interactive telephony service implied by 'talk'
>file/info -- intention is that there is a resource here to get information 
>(e.g. http:, https:, ftp:, ...)

this looks increasingly ugly to me ...  I just dont like it at all.

but if you feel you must my general feeling is that   the NAPTR field 
probably should follow some general convention such as <URI 
scheme>+<protocol>+<service>  with the assumption that some protocols can 
provide different types of services such as SMTP or tel etc .

>'voice' -- I think that this is similar to the 'talk' function described 
>above, but seems to specify that the result will be voice only (i.e. not 
>video & voice) and it might also allow VPIM messages - I hope not, but 
>this would need to be clarified.

Please can we let the VPIM people define how they wish to create 
enumservice fields.

I've yet to hear a rational argument ..that in the case of the protocol SIP 
..you need any of this ...WHY WHY do you need to say anything about talk or 
voice or video or IM or .. or anything ... If you have 2 NAPTR records that 
are SIP and one can only to text and the other one can only do voice ..then 
simply contact both if either proxy are properly configured it will define 
rules for each service type and reinvite the session.

>Rich suggests that a registrant should be able to provide a NAPTR without 
>specifying the capabilities or preference policies associated with a 
>resource identified within the (global) DNS.

Yes thank you ... I would prefer not to help create the greatest spamming 
database in the known world.

>I'd suggest that we add an "any" enumservice ("unspecified" works too, but 
>"any" is shorter :). In this way, a NAPTR with this enumservice does not 
>expose its applicability to DNS requesters.

NO ..just leave it blank ...  E2U+SIP    E2U+SMTP    the use of "any" 
itself is an exposure of capability.  your whole service field should be 
optional...

>Also, given that there may be more than one enumservice sub-field within a 
>single NAPTR (and given that this may be abnormal), the presence of "any" 
>together with one or more other enumservices within a single NAPTR means 
>that it can be considered not only for the other specified functions, but 
>for all functions - if the registrant does not wish to specify anything 
>further, I'd suggest that then any other enumservice sub-fields present 
>should be ignored.
>Although this seems to be a bizarre usage (having "any" plus some specific 
>enumservice), I think it MAY be used in some obscure non-terminal 
>processing cases. Any clarification here would be greatly appreciated.

all forms of service in the following structure should be optional PERIOD 
..<URI scheme>+<protocol>+<service>

>As an aside, this point on privacy is well taken. Any definition of "tel:" 
>URI parameter "svc" as proposed by Richard should specify "svc=any" as an 
>acceptable value; of course, in this case one may choose not to insert the 
>URI parameter at all.
>

tel is presumably the PSTN  but again ... it might be useful to 
have   E2U+tel+TDD orto find a terminal that is capable of text messaging 
for the hearing impared or something like that  or E2U+tel+fax for PSTN fax 
terminal..

Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
45980 Center Oak Plaza   Bldg 8     Sterling, VA  20166
1120 Vermont Ave NW Suite 400 Washington DC 20005
Voice +1 571.434.5651 Cell : +1 314.503.0640,  Fax: +1 815.333.1237
<mailto: [email-masked]> or
<mailto: [email-masked]>
<http://www.neustar.biz>
<http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 26 May 2002 18:50:23 +0200

What people have written is definitly not enough for saying anything of
what it all is about. People which suggest enumservices must write down
what the selection critera is.

Your summary is correct, but, it is also dangerous to draw too many
conclusions of what other people write.

I for example, and not suggested any services at all. As I am not a person
writing a client which might handle the TEL URI scheme, I don't know
whether I need to know more than the fact that TEL is used.

I.e. we need more text from the ones which want enumservices.

   paf

---

From: Lawrence Conroy <[email-masked]>
Date: Sun, 26 May 2002 18:42:41 +0100

(Redirecting to other thread on role of service field and enumservices)::

At 11:39 am -0400 26/5/02, Richard Shockey wrote:
(as comments on the schema set strawman)
>>srs -- intention is to act as a service resolution service (e.g. 
>>sip: or maybe ldap:)
>but if you feel you must my general feeling is that   the NAPTR 
>field probably should follow some general convention such as <URI 
>scheme>+<protocol>+<service>  with the assumption that some 
>protocols can provide different types of services such as SMTP or 
>tel etc .
>
>>only (i.e. not video & voice) and it might also allow VPIM messages 
>>- I hope not, but this would need to be clarified.
>
>
>I've yet to hear a rational argument ..that in the case of the 
>protocol SIP ..you need any of this ...WHY WHY do you need to say 
>anything about talk or voice or video or IM or .. or anything ... If 
>you have 2 NAPTR records that are SIP and one can only to text and 
>the other one can only do voice ..then simply contact both if either 
>proxy are properly configured it will define rules for each service 
>type and reinvite the session.
>
>
>>without specifying the capabilities or preference policies 
>>associated with a resource identified within the (global) DNS.
>
>Yes thank you ... I would prefer not to help create the greatest 
>spamming database in the known world.
>
>NO ..just leave it blank ...  E2U+SIP    E2U+SMTP    the use of 
>"any" itself is an exposure of capability.  your whole service field 
>should be optional...
>
>>presence of "any" together with one or more other enumservices 
>>within a single NAPTR means that it can be considered not only for 
>>the other specified functions, but for all functions - if the 
>>registrant does not wish to specify anything further, I'd suggest 
>>that then any other enumservice sub-fields present should be 
>>ignored.
>all forms of service in the following structure should be optional 
>PERIOD ..<URI scheme>+<protocol>+<service>
>
>tel is presumably the PSTN  but again ... it might be useful to have 
>E2U+tel+TDD orto find a terminal that is capable of text messaging 
>for the hearing impared or something like that  or E2U+tel+fax for 
>PSTN fax terminal..
>

To which I reply:
Hi Rich, folks,

I thought that protocol is as defined for registered URI-schemes, so
protocol proximates to URI-scheme. Is this incorrect?

Follow ups on syntax please to "enumservices & URI-scheme" thread.
See the proposal I collected/made in the "enumservices & URI-scheme" thread.
In short:
Using a "-" rather than a "+" to distinguish the URI-scheme sub-field
from subsequent enumservice sub-fields is intended to make parsing easier.
The URI-scheme sub-field may be missing (in the case of non-terminals).

IMHO, optional (or null) sub-fields make parsing more of a challenge.
I clarify - the "any" means unspecified or any - it's exactly the 
same as (blank / missing) sub-field value.
It does not expose anything more or less than leaving the field blank.

----

Follow ups on role of enumservice to "enumservice role" thread, please.

I absolutely do not intend to do anything on VPIM services - I'm no 
expert on this arcana (Is anyone ?).

Your comment that this is not needed with SIP - hey, 99% of the whole 
shebang is not needed if all you want is to populate the DNS with *a* 
SIP URL associated with the E164 number. Hmm..this could be 
registered with the SIP proxy/registrar anyway, so why do I need... 
That way lies the universe where the US is +666.

If the registrant doesn't want to put this information in to indicate 
that their .net account is going to be IM whilst their siptest 
account is going to be for voice, they don't have to do this. 
Absolutely agree that you can try both. Assuming that the 
proxy/registrar for each of the accounts is aware of the other one it 
will work fine.

However, IF the information is available then I'd like to use this in 
the client to short-circuit this. I'd sure like to display it in the 
UI (as you work in Washington D.C. rather than Washington State, I 
expect that you were thinking of displaying this before the client 
program went off and did something ?).

Question: From your comments, you think that at least the enumservice 
sub-field(s) is ugly/not useful. Is this correct?
If so, then why do we need to update 2916 at all; there's already a 
URI-scheme/"resolution protocol" sub-field in that?

Taking a more radical approach, you say that the whole of the 
services field content should be optional
(I guess you mean except for the "E2U" tag, as this is needed to 
delineate ENUM from some other D3S application).
Is this a proposal for a re-cast of 2916, making the "resolution 
protocol" sub-field optional?
It's a bit late in the day, but ...

And finally, folks, am I alone in having twats waste the paper in my 
fax machine suggesting I phone their premium rate number to express 
my views/...?
ENUM may be potentially the greatest spamming database in the whole 
world, but some folks seem to have such a database already...and, 
yes, I do hope their other one falls off.

all the best,
   Lawrence

---

From: Lawrence Conroy <[email-masked]>
Date: Sun, 26 May 2002 19:00:25 +0100

>I.e. we need more text from the ones which want enumservices.
Hi Patrik, folks,
I apologies for any mis-attribution - in an earlier post you said that you had
made a proposal. I looked and the only ones I could see where 
telvoice and sipvoice,
and then sip+voice, which I incorrectly assumed were potential enumservices
"sip" and "voice". In an attempt to be inclusive for the strawman, I 
included these.

Agreed, there needs to be more text before any client could fathom out what
to do with any of these enumservices. I hope others will join in.

One question - what do you mean by "selection criteria"?

all the best
  Lawrence

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 26 May 2002 21:01:01 +0200

> One question - what do you mean by "selection criteria"?

When a client see two NAPTR records, with two different enumservices, what
is the difference between the two? How is the client to know which one to
pick?

  paf