headers
Paul Kyzivat | 1 Mar 2005 01:38
Picon
Favicon

Re: [Geopriv] Re: presence authorization issue: anonymous, authenticated, etc.


Henning Schulzrinne wrote:
>> People can be very resourceful. It won't take long for somebody to 
>> begin to discern the pattern of addresses you use. (e.g. 
>> hgs+* <at> cs.columbia.edu)
>>
>> I think there will continue to be a demand for flexible techniques to 
>> denote specific classes of addresses based on patterns in the address.
> 
> Agreed, but we need to find a reasonable cut-off point of complexity and 
> predictability. You seem to be arguing for supporting general regular 
> expressions or at least "glob" style expressions, which is beyond what 
> we're currently describing, for either black or whitelists.

Yes, I think that something of that sort may be needed, or at least 
desirable. (glob style anyway.)

Something else that hasn't been touched upon is watchers whose identity 
is a tel uri. I think we have to expect that there will be such. Its 
ugly, but I think there will be need for special matching on various 
parts of these.

>> Yes. Its the bad apples list where you want a lot of flexibility in 
>> description. Note that I may not have to fully understand the domain 
>> name assignment policy to describe a matching algorithm sufficient for 
>> my needs. I may decide to simply exclude hgs* <at> cs.columbia.edu. This 
>> may overreach and exclude some I didn't intend to exclude, but that 
>> may still be ok, because I will never have need to correspond with 
>> them anyway.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Henning Schulzrinne | 1 Mar 2005 02:28

Re: [Geopriv] Re: presence authorization issue: anonymous, authenticated, etc.

Paul Kyzivat wrote:
> 

> Yes, I think that something of that sort may be needed, or at least 
> desirable. (glob style anyway.)

So far, prefix (for user names) and postfix (for hosts) seems to be 
working for the examples (which is also similar to the SQL "LIKE %" 
facility).

> 
> Something else that hasn't been touched upon is watchers whose identity 
> is a tel uri. I think we have to expect that there will be such. Its 
> ugly, but I think there will be need for special matching on various 
> parts of these.

I don't see tel:12*15*7

as all that useful.

> Yes, these are significant issues. Are you going to keep two different 
> sets of business cards and make a decision about which one to give to 
> someone? (The plain white ones, and the "platinum" ones.)

I suspect this is more useful for the address you put on your web page 
("is my shop open?") vs. your business card.

> I haven't got a particular mechanism in mind. But I agree there is some 
> similarity between saying "I calling but I just want your voicemail 
> server", and saying "I want whatever presence I can get without going
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Kyzivat | 1 Mar 2005 07:24
Picon
Favicon

Re: [Geopriv] Re: presence authorization issue: anonymous, authenticated, etc.


Henning Schulzrinne wrote:
> Paul Kyzivat wrote:
> 
>>
> 
>> Yes, I think that something of that sort may be needed, or at least 
>> desirable. (glob style anyway.)
> 
> 
> So far, prefix (for user names) and postfix (for hosts) seems to be 
> working for the examples (which is also similar to the SQL "LIKE %" 
> facility).

sip:* <at> *.columbia.edu ???

>> Something else that hasn't been touched upon is watchers whose 
>> identity is a tel uri. I think we have to expect that there will be 
>> such. Its ugly, but I think there will be need for special matching on 
>> various parts of these.
> 
> 
> I don't see tel:12*15*7
> 
> as all that useful.

agree that there is little utility in *full* generality. But I can see 
tel:+1978936*, tel:+1900*, or tel:*;phone-context=*.cisco.com. (And tel 
wildcard matching needs to know to ignore visual separators even when 
wildcarding - but maybe this is obvious.)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Miguel Garcia | 1 Mar 2005 15:13
Picon

Comments to MSRP-10

I am sending a few comments to version -10 of MSRP. They are mostly 
editorials.

1) Section 5.3, at the end of the 4th paragraph, the text reads:

    "A Failure-Report of "partial" is a way to report
    errors except timeouts.  The timeout error reporting requires the
    sending hop to run a timer and that receiving hop to send an
    acknowledgment to stop the timer.  Some systems don't want the
    overhead of doing this so choose not to but still allow error ..."

Well, in my opinion the sentence about the timeout is unintelligible, 
because this is the first time in the document we speak about timeouts, 
and people won't understand where this timeout can occur.

Since section 5 is informative in nature, I believe there is not hurry 
to discuss the timeout, which is further and well discuss later in the 
document.

So I would suggest that Section 5.3 just indicates that Failure-Report 
can also take the value "partial", and that the concept is further 
described in Section 7.1.1.

Alternatively you may want to add a full description of the timer, the 
timeout and the value of "partial", but I don't think it is needed in 
this section.

2) Section 5.4, 3rd paragraph:

    "Likewise, the active endpoint MUST immediately issue a SEND request.
(Continue reading)

Permalink | Reply | 37 comments |
headers
Paul Kyzivat | 1 Mar 2005 18:09
Picon
Favicon

Re: Comments to MSRP-10

Miguel - some good catches. A couple of comments.

	Paul

Miguel Garcia wrote:

> 6) Section 7.1.1., 6th paragraph:
> 
>    "Success-Report and Failure-Report MUST NOT be present for any method
>    other than SEND.  "
> 
> I would like to change the above sentence to be positive, rather than 
> negative, and add some scope. The motivation is that, in the future, we 
> may need to extend MSRP with a new method that contains Failure-Report 
> and Success-Report, and in such case we will be violating the above 
> text. So what about this:
> 
>    "Within the scope of the methods defined by this document, 
> Success-Report and Failure-Report headers MUST only be present (if 
> required) in SEND requests".

I don't find that helpful. I understand what the original is requiring, 
but with your suggestion I don't.

> 7) Section 7.3.1, last paragraph in the section
> 
>    "If the Success-Report header was set to "yes", then when a complete
>    message has been received, the receiver MUST send a success REPORT
>    with a byte range covering the whole message.  If the Success-Report
>    header is not set to "no", then the receiver MAY generate incremental
(Continue reading)

Permalink | Reply | 36 comments |
headers
Miguel Garcia | 1 Mar 2005 18:40
Picon

Re: Comments to MSRP-10

Paul:

Some comments inline, prepended by "Miguel -> "

Paul Kyzivat wrote:

> Miguel - some good catches. A couple of comments.
> 
>     Paul
> 
> Miguel Garcia wrote:
> 
>> 6) Section 7.1.1., 6th paragraph:
>>
>>    "Success-Report and Failure-Report MUST NOT be present for any method
>>    other than SEND.  "
>>
>> I would like to change the above sentence to be positive, rather than 
>> negative, and add some scope. The motivation is that, in the future, 
>> we may need to extend MSRP with a new method that contains 
>> Failure-Report and Success-Report, and in such case we will be 
>> violating the above text. So what about this:
>>
>>    "Within the scope of the methods defined by this document, 
>> Success-Report and Failure-Report headers MUST only be present (if 
>> required) in SEND requests".
> 
> 
> I don't find that helpful. I understand what the original is requiring, 
> but with your suggestion I don't.
(Continue reading)

Permalink | Reply | 35 comments |
headers
Paul Kyzivat | 1 Mar 2005 19:03
Picon
Favicon

Re: Comments to MSRP-10

more inline

	Paul

Miguel Garcia wrote:
> Paul:
> 
> Some comments inline, prepended by "Miguel -> "
> 
> Paul Kyzivat wrote:
> 
>> Miguel - some good catches. A couple of comments.
>>
>>     Paul
>>
>> Miguel Garcia wrote:
>>
>>> 6) Section 7.1.1., 6th paragraph:
>>>
>>>    "Success-Report and Failure-Report MUST NOT be present for any method
>>>    other than SEND.  "
>>>
>>> I would like to change the above sentence to be positive, rather than 
>>> negative, and add some scope. The motivation is that, in the future, 
>>> we may need to extend MSRP with a new method that contains 
>>> Failure-Report and Success-Report, and in such case we will be 
>>> violating the above text. So what about this:
>>>
>>>    "Within the scope of the methods defined by this document, 
>>> Success-Report and Failure-Report headers MUST only be present (if
(Continue reading)

Permalink | Reply | 17 comments |
headers
Miguel Garcia | 1 Mar 2005 19:19
Picon

Re: Comments to MSRP-10

Inline.

Paul Kyzivat wrote:

> more inline
> 
>     Paul
> 
> Miguel Garcia wrote:
> 
>> Paul:
>>
>> Some comments inline, prepended by "Miguel -> "
>>
>> Paul Kyzivat wrote:
>>
>>> Miguel - some good catches. A couple of comments.
>>>
>>>     Paul
>>>
>>> Miguel Garcia wrote:
>>>
>>>> 6) Section 7.1.1., 6th paragraph:
>>>>
>>>>    "Success-Report and Failure-Report MUST NOT be present for any 
>>>> method
>>>>    other than SEND.  "
>>>>
>>>> I would like to change the above sentence to be positive, rather 
>>>> than negative, and add some scope. The motivation is that, in the
(Continue reading)

Permalink | Reply | 16 comments |
headers
Paul Kyzivat | 2 Mar 2005 15:24
Picon
Favicon

Re: Comments to MSRP-10


Miguel Garcia wrote:

>>> Miguel -> I don't really care about the exact wording, as long as it 
>>> does not make any assumptions about future MSRP extensions. The 
>>> current text implies that the Report headers are meant only for SEND 
>>> requests, and for no other MSRP methods that any human can think of 
>>> in the future. So if we invent a new method that can use those 
>>> headers, this shouldn't create a violation of the MSRP RFC
>>
>> OK. I can buy that. I see two ways to achieve that:
>> - Say that Success-Report and Failure-Report MUST NOT be used in a
>>   request or response unless permitted by specific normative text.
>>   The normative text will only be present for SEND.
>>
>> - Introduce a table like Table 2 of 3261 (I think it is table 2),
>>   specifying which headers may be used with which requests and
>>   responses.
>>
>> I prefer the table.
> 
> I know that some people hates this table... but I am fine with it, I 
> find it very useful.

I'm not wild about the table either, but it seems to beat the alternatives.

>>>>> 7) Section 7.3.1, last paragraph in the section
>>>>>
>>>>>    "If the Success-Report header was set to "yes", then when a 
>>>>> complete
(Continue reading)

Permalink | Reply | 15 comments |
headers
Hyttfors, Per | 2 Mar 2005 21:12

draft-ietf-simple-xcap-06 Parsing of an XCAP URI

Hello Everyone,

Is it possible to parse an XCAP URI and unambiguously identifying all
the different XCAP URI segments (like the XCAP root, AUID etc) in an
absolute URI?

Since the XCAP specification allows the XCAP root (as well as the
document selector) to have all kinds of path segments, how can I then
find all the XCAP segments in the URI without prior knowledge and
removal of the XCAP root?

I've looked for a restriction in the XCAP specification to make this
parsing possible, like that the "/users/" and the "/global/" segments
were disallowed in the XCAP root, but I did not find it. Did I miss
something vital or is the XCAP URI not designed to be parsed out of
context?

I have also not found any restriction that makes the path separator
"/~~/" segment globally unique. As I understand only the node selector
is prohibited from having that segment, caused by the XML requirements
on QName.

/Per
Permalink | Reply | 0 comments |

Gmane